linux-kernel - Re: [RFC PATCH 0/3] futex: Add support task local hash maps.

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]

Message-ID: <87froh50g2.ffs@tglx>
Date: Sun, 27 Oct 2024 11:01:33 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 linux-kernel@...r.kernel.org
Cc: André Almeida <andrealmeid@...lia.com>, Darren Hart
 <dvhart@...radead.org>, Davidlohr Bueso <dave@...olabs.net>, Ingo Molnar
 <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>, Peter Zijlstra
 <peterz@...radead.org>, Valentin Schneider <vschneid@...hat.com>, Waiman
 Long <longman@...hat.com>
Subject: Re: [RFC PATCH 0/3] futex: Add support task local hash maps.

On Sun, Oct 27 2024 at 00:34, Sebastian Andrzej Siewior wrote:
> and adds support for task local futex_hash_bucket. It can be created via
> prctl() and each thread has to enable it via another prctl() interface.

That's a quick way to evaluate it.

> Individual threads may enable it but I guess this gets more complicated
> because the libc internal locks (or another lib) maybe be shared by
> multiple threads. So maybe it would be best to enable the local hash by
> the group leader and automatically enable for each thread on fork().

At the end we want to let the kernel automatically create the hash table
on first use of a private futex with a default size. That's a one off
latency. The prctl should only be there for preallocation and sizing.

And yes, you want to inherit when a new thread is created.

Thanks,

        tglx