On Wed, Feb 1, 2023 at 12:21 AM Helge Deller <deller@xxxxxx> wrote:
>
> AFAICS, the only applications which really care about the return
> code are
> - testsuites like LTP (i.e. the fstat05 testcase)
Those have actually shown issues with various library implementations,
exactly because real system calls act very differently in this area
from library wrappers.
Things like the vdso implementation of gettimeofday() get a SIGSEGV if
the timeval or timezone pointer is invalid, while the "real system
call" version returns -1/EFAULT instead.
And very similar things happen when glibc ends up wrapping system
calls and converting buffers manually. At some point, glibc had a
special 'struct stat' and basically converted the native system call
to it, so you did 'stat()' on something, and it ended up actually
using a private on-stack buffer for the system call, followed by a
"convert that kernel 'struct stat' to the glibc 'struct stat'" phase.
So once again, instead of -1/EFAULT, you'd first have a successful
system call, and then get a SIGSEGV in glibc.
And as you say, test suites would notice. But no actual normal app
would ever care.
Of course, there's always the abnormal apps. There _are_ the odd cases
that actually catch faults and fix them up, and can then be confused
by changes like that.
It's very very rare, but it happens - things like emulators do tend to
do some really strange things.
Linus
|