History log of /bionic/libc/arch-x86/syscalls/___close.S
Revision Date Author Comments
9ce09e423f24823d52f19ab8247e078977100132 12-Nov-2015 Mingwei Shi <mingwei.shi@intel.com> libc: implement kernel vdso syscalls for i386

This patch uses __kernel_vsyscall instead of "int 0x80"
as the syscall entry point. AT_SYSINFO points to
an adapter to mask the arch specific difference and gives a
performance boost on i386 architecture.

Bug: http://b/27533895
Change-ID: Ib340c604d02c6c25714a95793737e3cfdc3fc5d7
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>

(cherry picked from commit be910529322b461148debefd50b9e0d67ae84f8e)
be910529322b461148debefd50b9e0d67ae84f8e 12-Nov-2015 Mingwei Shi <mingwei.shi@intel.com> libc: implement kernel vdso syscalls for i386

This patch uses __kernel_vsyscall instead of "int 0x80"
as the syscall entry point. AT_SYSINFO points to
an adapter to mask the arch specific difference and gives a
performance boost on i386 architecture.

Change-ID: Ib340c604d02c6c25714a95793737e3cfdc3fc5d7
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
3391a9ff139d57fe4f8a2ff2d81a5ddc230a6208 23-Apr-2015 Elliott Hughes <enh@google.com> Simplify close(2) EINTR handling.

This doesn't affect code like Chrome that correctly ignores EINTR on
close, makes code that tries TEMP_FAILURE_RETRY work (where before it might
have closed a different fd and appeared to succeed, or had a bogus EBADF),
and makes "goto fail" code work (instead of mistakenly assuming that EINTR
means that the close failed).

Who loses? Anyone actively trying to detect that they caught a signal while
in close(2). I don't think those people exist, and I think they have better
alternatives available.

Bug: https://code.google.com/p/chromium/issues/detail?id=269623
Bug: http://b/20501816
Change-Id: I11e2f66532fe5d1b0082b2433212e24bdda8219b