Message ID | 20201118195552.2687336-1-adhemerval.zanella@linaro.org |
---|---|
Headers | show |
Series | More Linux syscall refactor | expand |
This series introduces assumptions that various socket syscalls are available. That's not valid until the minimum Linux kernel version has been increased to at least 4.4 (depending on the architecture, but probably such a change would be done globally). In the case of getpeername and getsockname, at least, it's not safe (for 32-bit SPARC under 64-bit kernels) until Linux 4.20 - in general, before assuming a syscall to be present after any increase of the minimum Linux kernel version, it's important to review the actual state of support for that syscall in the minimum kernel version, including in compat syscall tables. As I previously noted <https://sourceware.org/pipermail/libc-alpha/2020-July/116453.html>, I think we ought to implement Carlos's proposal of removing the runtime check for old kernel versions before increasing the minimum kernel version, given that an increased version allows very little cleanup for e.g. x86_64. I also think that, when assuming presence of a syscall reduces the C implementation of a socket function to just calling a single syscall unconditionally, having one line for that function in a single syscalls.list file is better than having a manually-maintained C implementation.
On 18/11/2020 18:06, Joseph Myers wrote: > This series introduces assumptions that various socket syscalls are > available. That's not valid until the minimum Linux kernel version has > been increased to at least 4.4 (depending on the architecture, but > probably such a change would be done globally). In the case of > getpeername and getsockname, at least, it's not safe (for 32-bit SPARC > under 64-bit kernels) until Linux 4.20 - in general, before assuming a > syscall to be present after any increase of the minimum Linux kernel > version, it's important to review the actual state of support for that > syscall in the minimum kernel version, including in compat syscall tables. The idea of this socket changes is to align with default Linux kernel ABI, to make the outliers to explicit disable the syscall support where applicable and simplify the relation netweenn the syscalls.list and the required C implementations. The 'bind', for instance, is not listed on sysdeps/unix/sysv/linux/syscalls.list, so ports that do not imply on 'generic' will need to explicit disable on the kernel-features.h. Another idea of this change it to eventually remove the sysdeps/unix/sysv/linux/generic/ and make sysdeps/unix/sysv/linux the default implementation. And the idea is not change any current assumption, my goal is just reorganize the code. For getpeername and getsockname is indeed wrong assumption in my patch, it should disable both for !__arch64__ && __LINUX_KERNEL_VERSION < 0x040400. > > As I previously noted > <https://sourceware.org/pipermail/libc-alpha/2020-July/116453.html>, I > think we ought to implement Carlos's proposal of removing the runtime > check for old kernel versions before increasing the minimum kernel > version, given that an increased version allows very little cleanup for > e.g. x86_64. I thing this change is orthogonal to what I am proposing here. > > I also think that, when assuming presence of a syscall reduces the C > implementation of a socket function to just calling a single syscall > unconditionally, having one line for that function in a single > syscalls.list file is better than having a manually-maintained C > implementation. > I do agree, and my proposal here in once we have a proper support for direct syscall with bump minimal kernel support we can just remove the C implementation and move it to syscalls.list without the need to change and rework over various files.
On Thu, 19 Nov 2020, Adhemerval Zanella wrote: > And the idea is not change any current assumption, my goal is just reorganize > the code. Then I think the individual patches need longer descriptions that make this clear - that is, that say explicitly that the change is to the default, with the final value of the __ASSUME_* macro being unchanged for all glibc configurations. Because that's not what e.g. "Assume bind support" suggests to me. > For getpeername and getsockname is indeed wrong assumption in my > patch, it should disable both for !__arch64__ && __LINUX_KERNEL_VERSION < 0x040400. 4.20 for those two, I think, because of the compat syscall table.
On 19/11/2020 13:38, Joseph Myers wrote: > On Thu, 19 Nov 2020, Adhemerval Zanella wrote: > >> And the idea is not change any current assumption, my goal is just reorganize >> the code. > > Then I think the individual patches need longer descriptions that make > this clear - that is, that say explicitly that the change is to the > default, with the final value of the __ASSUME_* macro being unchanged for > all glibc configurations. Because that's not what e.g. "Assume bind > support" suggests to me. Fair enough, I will improve the message on the patches. > >> For getpeername and getsockname is indeed wrong assumption in my >> patch, it should disable both for !__arch64__ && __LINUX_KERNEL_VERSION < 0x040400. > > 4.20 for those two, I think, because of the compat syscall table. > Right, I will fix this also.