Re: [PATCH v1 05/14] futex: Add sys_futex_wake()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 21, 2023, at 20:54, Peter Zijlstra wrote:
> On Fri, Jul 21, 2023 at 05:41:20PM +0200, Arnd Bergmann wrote:
>> On Fri, Jul 21, 2023, at 12:22, Peter Zijlstra wrote:
>> > --- a/kernel/sys_ni.c
>> > +++ b/kernel/sys_ni.c
>> > @@ -87,6 +87,7 @@ COND_SYSCALL_COMPAT(set_robust_list);
>> >  COND_SYSCALL(get_robust_list);
>> >  COND_SYSCALL_COMPAT(get_robust_list);
>> >  COND_SYSCALL(futex_waitv);
>> > +COND_SYSCALL(futex_wake);
>> >  COND_SYSCALL(kexec_load);
>> >  COND_SYSCALL_COMPAT(kexec_load);
>> >  COND_SYSCALL(init_module);
>> 
>> This is fine for the moment, but I wonder if we should start making
>> futex mandatory at some point. Right now, sparc32 with CONFIG_SMP
>> cannot support futex because of the lack of atomics in early
>> sparc processors, but sparc32 glibc actually requires futexes
>> and consequently only works on uniprocessor machines, on sparc64
>> compat mode, or on Leon3 with out of tree patches.
>
> PARISC is another 'fun' case.

I had to look up how that works, but as far as I can tell, the
parisc code actually has a chance of working, as the userspace
atomics go through the light-weight syscall that shares a hashed
lock with the actual futex syscall. On sparc32 I think it's
worse because userspace assumes that atomic instructions are
supported while the kernel assumes they are not.

        Arnd




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux