Re: glibc 2.27: less than two weeks till release

[Joseph Myers <joseph at codesourcery dot com>]

On Sun, 28 Jan 2018, Romain Naour wrote:

> > The microblaze/kernel-features.h needs to undefine 
> > __ASSUME_COPY_FILE_RANGE under such a condition, yes, much like it handles 
> > various other syscalls added later than on other architectures - but it 
> > would be appropriate to make a check for all glibc architectures to see if 
> > there are any others for which the default (>= 4.5) definition of 
> > __ASSUME_COPY_FILE_RANGE is wrong.
> > 
> 
> For now, I only tested with kernel headers 4.9 on several architectures (arm,
> aarch64, x86, x86-64, powerpc, powerpc64, nios2, sh, sparc).
> 
> copy_file_range has been added for xtensa in 4.9, sh in 4.8, aarch64 in 4.7, so
> the default (>= 4.5) definition of __ASSUME_COPY_FILE_RANGE is wrong for them.

That aarch64 change looks like it was just for the compat syscall table 
(so possibly relevant for the arm port), not for the normal one?

(glibc doesn't support xtensa; there is/was a port, but it's never been 
upstreamed.)

It seems alpha added mlock2 and copy_file_range only in 4.13 (kernel 
commit a720830613eaa25eb5bc9b76705a88a36296709a - which has a load of 
other syscalls as well, but not ones that currently have __ASSUME_* 
macros).  There may well be other such issues; a proper review is 
certainly needed.  Things were correct (based on my review) as of glibc 
commit 6d08b0223aa3b3152ea7e9beb2b8f2a151b43109; it's __ASSUME_EXECVEAT, 
__ASSUME_MLOCK2 and __ASSUME_COPY_FILE_RANGE that need careful attention 
to when each architecture actually added the syscall to both asm/unistd.h 
and the syscall table.

-- 
Joseph S. Myers
joseph@codesourcery.com