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 03/15] sparc: Use Linux kABI for syscall return



On 11/02/2020 18:15, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> But ERESTART_RESTARTBLOCK is not 4095, so glibc with this change will
>>> now treat certain internal kernel error codes as errors, while they
>>> were previously reported as success.  This looks like a kernel bug, in
>>> that ERESTART_RESTARTBLOCK was not updated when more error codes were
>>> added.  On the other hand, these error codes should never leak into
>>> userspace.
>>
>> My understanding is such errors should not be visible by the application,
>> as indicated by include/linux/errno.h comment. And it seems to be the
>> case for sparc, at least on:
> 
> These error codes tend to leak from device drivers and other less
> scrutinized parts of the kernel.  It's not actually about the
> ERESTART_RESTARTBLOCK value as such, there are other values larger
> than that:
> 
> #define ERESTART_RESTARTBLOCK 516 /* restart by calling sys_restart_syscall */
> #define EPROBE_DEFER    517     /* Driver requests probe retry */
> #define EOPENSTALE      518     /* open found a stale dentry */
> #define ENOPARAM        519     /* Parameter not supported */
> 
> /* Defined for the NFSv3 protocol */
> #define EBADHANDLE      521     /* Illegal NFS file handle */
> #define ENOTSYNC        522     /* Update synchronization mismatch */
> #define EBADCOOKIE      523     /* Cookie is stale */
> #define ENOTSUPP        524     /* Operation is not supported */
> 
> And so on.
> 
> Like I said, it looks like someone forgot to update this code.  It
> probably should use the 4095 boundary and not specific error codes
> anyway.  (We had a similar problem in glibc itself in the s390
> socketcall support.)
This code seems to come from since initial git repository 
(Linux-2.6.12-rc2).

>From a glibc standpoint, the error handling will be the same in fact,
since what indicates the syscall has failed is the carry condition code
value, not the syscall returned value ('o0' register).


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