linux-kernel - Re: [PATCH v1 05/14] futex: Add sys_futex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Jul 2023 23:23:27 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Peter Zijlstra" <peterz@...radead.org>
Cc:     "Thomas Gleixner" <tglx@...utronix.de>,
        "Jens Axboe" <axboe@...nel.dk>, linux-kernel@...r.kernel.org,
        "Ingo Molnar" <mingo@...hat.com>,
        "Darren Hart" <dvhart@...radead.org>, dave@...olabs.net,
        andrealmeid@...lia.com,
        "Andrew Morton" <akpm@...ux-foundation.org>, urezki@...il.com,
        "Christoph Hellwig" <hch@...radead.org>,
        "Lorenzo Stoakes" <lstoakes@...il.com>, linux-api@...r.kernel.org,
        linux-mm@...ck.org, Linux-Arch <linux-arch@...r.kernel.org>,
        malteskarupke@....de
Subject: Re: [PATCH v1 05/14] futex: Add sys_futex_wake()

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