Re: [RFC][PATCH 04/10] futex: Add sys_futex_wake()

[Arnd Bergmann]

On Fri, Jul 14, 2023, at 16:47, Peter Zijlstra wrote:
> On Fri, Jul 14, 2023 at 04:26:45PM +0200, Arnd Bergmann wrote:
>> On Fri, Jul 14, 2023, at 15:39, Peter Zijlstra wrote:
>> >
>> > +++ b/include/linux/syscalls.h
>> > @@ -563,6 +563,9 @@ asmlinkage long sys_set_robust_list(stru
>> >  asmlinkage long sys_futex_waitv(struct futex_waitv *waiters,
>> >  				unsigned int nr_futexes, unsigned int flags,
>> >  				struct __kernel_timespec __user *timeout, clockid_t clockid);
>> > +
>> > +asmlinkage long sys_futex_wake(void __user *uaddr, int nr, unsigned 
>> > int flags, u64 mask);
>> > +
>> 
>> You can't really use 'u64' arguments in portable syscalls, it causes
>> a couple of problems, both with defining the user space wrappers,
>> and with compat mode.
>> 
>> Variants that would work include:
>> 
>> - using 'unsigned long' instead of 'u64'
>> - passing 'mask' by reference, as in splice()
>> - passing the mask in two u32-bit arguments like in llseek()
>> 
>> Not sure if any of the above work for you.
>
> Durr, I was hoping they'd use register pairs, but yeah I can see how
> that would be very hard to do in generic code.

It kind of works to just use register pairs, the actual problem
you run into here is that:

- depending on the architecture, the register pairs need to be
  even/odd pairs, so there are two different ways that 32-bit
  architectures handle it

- The compat handler needs to explicitly name the registers that
  are used, so to make your version above work correctly, we'd
  need three entry points, for native 64-bit, compat 32-bit
  odd/even pairs and compat 32-bit even/odd pairs.

> Hurmph.. using 2 u32s is unfortunate on 64bit, while unsigned long
> would limit 64bit futexes to 64bit machines (perhaps not too bad).
>
> Using unsigned long would help with the futex_wait() thing as well.
>
> I'll ponder things a bit.
>
> Obviously I only did build x86_64 ;-)

I suspect that restricting the futexes to native work size is
ok since many 32-bit architectures don't have 64-bit atomic
instructions anyway (armv6k+ and i586tsc+ being the obvious
exceptions), so userspace code that relies on it becomes
nonportable.

    Arnd