clock_gettime after 2.31 and reused syscall numbers

clock_gettime after 2.31 and reused syscall numbers

[Dan Christensen]

Hello,

My understanding is that after glibc 2.31 clock_gettime can call
clock_gettime64 from a 32-bit process to get a 64-bit time_t if the
underlying kernel supports such a thing.  The problem I ran into was
that a particular Synology kernel version (3.10.77) included their own
system calls for whatever product specific purpose they may have
wanted, including one at 403 (SYNOArchiveBit) which is where Linux 5.1
added clock_gettime64.

This resulted in glibc >= 2.31 trying to call that proprietary
function instead of falling back to clock_gettime.  Which in a trivial
test case saw both struct timespec members be 0.  But in the actual
application that triggered digging into this issue saw a thread hit
99% CPU usage and not be able to yield due to clock_gettime64 (but
really SYNOArchiveBit) returning EINVAL.

In glibc <= 2.28 clock_gettime is called and no problem nor loss of
time_t precision is realized.

I'm curious if glibc should even try to handle this case?
Part of why I ask is because [1] seems to suggest that it may have
been most appropriate to examine the vDSO for the presence of a
clock_gettime64 symbol before trying to go down the path of invoking
that function.
Or is all of that out of scope because "a vendor deviated from
mainline, and such things are impossible to predict or support"?  I
don't mean to suggest that to be an unreasonable position.

Thanks for your time,
Dan

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=ec138c67cbda8b5826a0a2a7ba456408117996dc

Re: clock_gettime after 2.31 and reused syscall numbers

[Florian Weimer]

* Dan Christensen:

> Or is all of that out of scope because "a vendor deviated from
> mainline, and such things are impossible to predict or support"?

Yes, that's basically it.  If the system calls do not work as in
mainline Linux, there is little we can do about it.

In this particular case, it only affects 32-bit and no major
distribution kernels, so there isn't a very compelling reason to support
this.

Thanks,
Florian