This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH-for-2.21-and-2.22] s390-64: remove socketcall syscalls


On 2015-12-31 22:13, Aurelien Jarno wrote:
> On 2015-12-31 18:21, Joseph Myers wrote:
> > On Fri, 25 Dec 2015, Aurelien Jarno wrote:
> > 
> > > From: Stefan Liebler <stli@linux.vnet.ibm.com>
> > > 
> > > Remove socketcalls in syscalls.list for s390-64. They were never used
> > > on s390x and produce wrong code when glibc is built against 4.3 kernel
> > > headers.
> > 
> > Could you explain why they produce wrong code?
> 
> I personally haven't checked. I have seen that compiling glibc against
> 4.3 kernel headers produced this wrong code. I then looked on master and
> then realized these syscalls have been removed from syscalls.list. I
> haven't really investigating more given I though the problem was
> understood.
> 
> All that said we don't want these syscalls to be used as soon as we use
> recent enough kernel headers as the resulting libc might be then used on
> an older kernel.
> 
> > Long term, once we can assume a kernel with direct socket syscalls on all 
> > architectures, we should get rid of socketcall support.  And the preferred 
> > form of getting rid of it isn't to have lots of C files calling syscall 
> > macros.  It's to use syscalls.list entries where possible, with C files 
> > only if needed because e.g. a function doesn't correspond directly to a 
> > syscall (Adhemerval's cancellation changes would add "syscall is a 
> > cancellation point" to the cases needing C files; I'm unconvinced that 
> > reducing the number of cases that can use syscalls.list is a good idea).  
> > And those syscalls.list entries would where possible be those in 
> > sysdeps/unix/syscalls.list (appropriately adjusted to be in sync with the 
> > current Linux-specific entries as needed).
> > 
> > So, if there are cases where listing such a syscall in syscalls.list 
> > produces wrong code, we need to understand those cases properly so we can 
> > allow for them in the future when eliminating socketcall support and using 
> > syscalls.list entries in more cases, architecture-independent.
> 
> Ok, I'll try to investigate in the next days.

I have found some times to investigate. It seems there is no issue, my
bad. I just discovered that on s390x, syscalls numbers above 256 are
actually a a call to syscall 0 with the syscall number passed in
register %r1. My version of strace was not aware of the new syscalls 
and presented them as syscall setup(). Sorry for the false alert.

So it seems all is fine, but we still need the patch to use the
socketcall interface until we can assume the direct socket syscalls are
always available. I'll repost the patch on the libc-stable interface
with the comment fixed, as I have been told in the meantimes it's a
better list for discussing about already released versions.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]