This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/2] kernel-features: fix accept4 kernel versions
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Aurelien Jarno <aurelien at aurel32 dot net>
- Cc: <libc-alpha at sourceware dot org>, Ryan S Arnold <rsa at linux dot vnet dot ibm dot com>, Steven Munroe <munroesj at linux dot vnet dot ibm dot com>, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, Martin Schwidefsky <schwidefsky at de dot ibm dot com>
- Date: Sun, 1 Dec 2013 19:08:28 +0000
- Subject: Re: [PATCH 1/2] kernel-features: fix accept4 kernel versions
- Authentication-results: sourceware.org; auth=none
- References: <1385900405-27783-1-git-send-email-aurelien at aurel32 dot net>
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
* 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