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: [RFC v2 06/20] sysdeps/futex: Use futex_time64 if avaliable


* Arnd Bergmann:

> On Tue, Jun 25, 2019 at 1:26 PM Andreas Schwab <schwab@suse.de> wrote:
>> On Jun 25 2019, Florian Weimer <fweimer@redhat.com> wrote:
>> >
>> > I don't think a compile-time check in generic code is correct here.  It
>> > will cause binaries to fail to run on older kernels which do not have
>> > the system call.  This is obviously not a concern for 32-bit RISC-V, but
>> > it is not acceptable for i386, for example.
>> >
>> > I still think you should define __NR_futex in RV32 <sysdep.h>.
>>
>> For existing 32-bit archs there needs to be a runtime check (if both
>> __NR_futex and __NR_futex_time64 are defined).
>
> That opens the question what type this function should take,
> because one of the two will require the time argument to be
> converted.
>
> For instance pthread_timedjoin_np() is a public interface
> that will need an additional version to deal with time64.
> Should pthread_timedjoin_np() convert the user timespec
> to __timespec64 and pass it down to lll_futex_syscall(),
> which then converts it back to timespec before calling
> __NR_futex() on 32-bit architectures, or is there a way to
> avoid the double conversion?

My expectation is that glibc will not provide a 32-bit struct timespec
for architectures which do not have a 32-bit __NR_futex system call.
It's a 64-bit only world.  Before the 2038 deadline, we will not support
kernels that removed support for the 32-bit system calls.

Based on that, I expect that the 32-bit struct timespec variant of
pthread_timedjoin_np calls futex, and the 64-bit variant (probably named
pthread_timedjoin64_np or something like that, or used by default under
appropriate feature selection macros) will call futex_time64.  This has
the advantage that the type of call is visible at the syscall layer, and
could eventually trigger kenrel warnings.  With translation, that
wouldn't be the case.  It also increases compatibility with seccomp
filters which know of the old system calls, but not the new ones.

Thanks,
Florian


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