Re: [PATCH 1/2] kernel-features: fix accept4 kernel versions

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Sun, 1 Dec 2013, Aurelien Jarno wrote:

> accept4 has been added for
> - x86/x86-64 in 2.6.28 (commit de11defebf00007677fb7ee91d9b089b78786fbb)
> - sparc in 2.6.28 (commit f8b2256e9c11a825899345de06b39a4bdf44911d)
> - powerpc in 2.6.37 (commit 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6)
> 
> It has not been added on s390, the syscall number doesn't exist.

But __ASSUME_ACCEPT4 isn't just about the syscall - and when addressing 
issues with the kernel versions for __ASSUME_*, you need first to 
ascertain exactly what the macro actually means.

__ASSUME_ACCEPT4 is used in two ways:

* In OS-independent code, to mean "accept4 can be assumed to work rather 
than fail with ENOSYS".  It doesn't matter whether it's implemented with 
socketcall or a separate syscall.

* In Linux-specific code, to mean "the socketcall multiplex syscall can be 
assumed to handle the accept4 operation.  When used in Linux-specific 
code, it *never* refers to anything relating to the accept4 syscall, only 
to the socketcall multiplexer.

Now, on all architectures with the socketcall multiplexer, the first 
commit to which you refer added the required support.  That includes s390.

So the following architectures, using socketcall in glibc, got support 
through socketcall in 2.6.28 (or as long as they've been in the Linux 
kernel, if added later): am33 i386 m68k microblaze powerpc s390 sh sparc.  
This leaves the following issues:

* aarch64 alpha arm hppa ia64 mips tile x86_64 do not use socketcall in 
glibc.  Of these, some already define __ASSUME_ACCEPT4, and without having 
checked the versions for which they define it I have no reason to suspect 
them of being wrong.  For such architectures, it must be defined for the 
kernel version that gained the syscall (wired up in the syscall table as 
well as in asm/unistd.h).  hppa and mips don't define it - both do now 
have the syscall, so both kernel-features.h files need updating 
appropriately.

* microblaze powerpc sh sparc define the syscall but use socketcall in 
glibc.  This is only a problem if the syscall was added in a version later 
than 2.6.28.  In that case, the glibc code would just use the accept4 
syscall if __NR_accept4 is defined, when a wider range of kernels would be 
better supported if there were fallback to use of socketcall.  Now:

  - For microblaze, 2.6.33 and later have 
    4a3bb9a90083c064031f15c2ac38bcf68c3487e6 adding the syscall.

  - For powerpc, you identified 2.6.37 and later as having 
    86250b9d12caa1a3dee12a7cf638b7dd70eaadb6 adding the syscall.

  - For sh, 2.6.37 and later have 21b6e4c7106b2d68a6710506d8706608272fd78b 
    adding the syscall.

  - For sparc, you identified 2.6.28 and later as having 
    f8b2256e9c11a825899345de06b39a4bdf44911d adding the syscall.

So, your patch is incorrect for s390, while for powerpc it's suboptimal.  
For hppa the relevant commit is 81e4a5e3057740a625cf556879ae0becf6199f8c 
(2.6.34 and later).

To address microblaze, powerpc and sh optimally, the right approach would 
probably be to separate __ASSUME_ACCEPT4 (describing whether the function 
can be assumed to work), __ASSUME_ACCEPT4_SYSCALL (the Linux syscall) and 
__ASSUME_ACCEPT4_SOCKETCALL.  __ASSUME_ACCEPT4_SOCKETCALL would be defined 
for versions 2.6.28 and later, for all architectures using socketcall in 
glibc (but I suppose not for other architectures).  
__ASSUME_ACCEPT4_SYSCALL would be defined in an architecture-specific way.  
__ASSUME_ACCEPT4 would be defined if either __ASSUME_ACCEPT4_SYSCALL or 
__ASSUME_ACCEPT4_SOCKETCALL.  The code using the accept4 syscall in 
sysdeps/unix/sysv/linux/accept4.c would have a fallback to socketcall in 
the case that __NR_accept4 is defined but __ASSUME_ACCEPT4_SYSCALL isn't, 
for the affected architectures (but not for other architectures that don't 
use socketcall in glibc, or where the accept4 syscall was added in 
2.6.28).  And internal_accept4.S would need to define the required 
__internal_accept4 in the case.

There is I suppose the possibility that more architectures will add the 
accept4 syscall where previously socketcall was used, which would cause 
breakage similar to that for microblaze, powerpc and sh.  So rather than 
hardcoding special cases just for those architectures and risk others 
breaking in future if new kernel headers are added, it might be better to 
have a macro __ASSUME_ACCEPT4_SYSCALL_NO_FALLBACK and define it for the 
cases of existing architectures that added the syscall in 2.6.28, or added 
it later but don't use socketcall in glibc.  (There's no need to define it 
for architectures that had the syscall from when they were added to the 
Linux kernel because they'll just define __ASSUME_ACCEPT4_SYSCALL.)

-- 
Joseph S. Myers
joseph@codesourcery.com