From: Thomas Gleixner <tglx@linutronix.de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-kernel@vger.kernel.org
Cc: "André Almeida" <andrealmeid@igalia.com>,
"Darren Hart" <dvhart@infradead.org>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"Ingo Molnar" <mingo@redhat.com>,
"Juri Lelli" <juri.lelli@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Valentin Schneider" <vschneid@redhat.com>,
"Waiman Long" <longman@redhat.com>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>
Subject: Re: [RFC PATCH 2/3] futex: Add basic infrastructure for local task local hash.
Date: Sun, 27 Oct 2024 13:19:54 +0100 [thread overview]
Message-ID: <87cyjl4u1h.ffs@tglx> (raw)
In-Reply-To: <20241026224306.982896-3-bigeasy@linutronix.de>
On Sun, Oct 27 2024 at 00:34, Sebastian Andrzej Siewior wrote:
> static void futex_cleanup(struct task_struct *tsk)
> {
> + struct futex_hash_table *fht;
> + bool need_free = false;
> +
> if (unlikely(tsk->robust_list)) {
> exit_robust_list(tsk);
> tsk->robust_list = NULL;
> @@ -1054,6 +1064,23 @@ static void futex_cleanup(struct task_struct *tsk)
>
> if (unlikely(!list_empty(&tsk->pi_state_list)))
> exit_pi_state_list(tsk);
> +
> + rcu_read_lock();
> + fht = rcu_dereference(current->futex_hash_table);
> + if (fht) {
> +
> + spin_lock(&fht->lock);
I don't think you need a spin lock for this.
> + fht->users--;
> + WARN_ON_ONCE(fht->users < 0);
> + if (fht->users == 0)
> + need_free = true;
> + spin_unlock(&fht->lock);
> + rcu_assign_pointer(current->futex_hash_table, NULL);
> + }
> + rcu_read_unlock();
scoped_guard (rcu) {
fht = rcu_dereference(current->futex_hash_table);
if (fht && rcuref_put_rcusafe(&fht->refcnt)
rcu_assign_pointer(current->futex_hash_table, NULL);
else
fht = NULL;
}
kfree_rcu_mightsleep(fht);
Hmm? But see below
> +static int futex_hash_allocate(unsigned long arg3, unsigned long arg4,
> + unsigned long arg5)
> +{
> + unsigned int hash_slots = arg3;
> + struct futex_hash_table *fht;
> + size_t struct_size;
> + int i;
> +
> + if (hash_slots == 0)
> + hash_slots = 4;
> + if (hash_slots < 2)
> + hash_slots = 2;
> + if (hash_slots > 16)
> + hash_slots = 16;
> + if (!is_power_of_2(hash_slots))
> + hash_slots = rounddown_pow_of_two(hash_slots);
> +
> + if (current->futex_hash_table)
> + return -EALREADY;
You also need to check whether a hash table exists already in the
process. The table must be process shared to make sense. So it should
live in current->signal, which is a valid pointer in the context of
current.
So this needs some more thoughts especially vs. automatic creation and
sharing.
The first question is whether the hash table might have been already
created when the application reaches main(). If so then this call will
fail.
To make this work correctly, this needs proper serialization as well.
Assume a situation where the application does not allocate a table
upfront and the first futex use happens late when threads are running
already.
CPU0 CPU1
T1 T2
sys_futex() sys_futex()
create_hash() create_hash()
So T1 and T2 create their local hash and the subsequent usage will fail
because they operate on different hashs. You have the same problem
vs. your allocation scheme when two threads do prctl(ALLOC). We really
want to make this as simple as possible.
sys_futex()
...
if (private)
hash = private_hash(current);
else
hash = &global_hash;
private_hash()
hash = READ_ONCE(current->signal->futex_hash);
if (hash)
return hash;
guard(spinlock_irq)(&task->sighand->siglock);
hash = current->signal->futex_hash;
if (hash))
return hash;
hash = alloc_hash();
WRITE_ONCE(current->signal->futex_hash, hash);
return hash;
alloc_hash()
if (!local_hash_enabled)
return &global_hash;
hash = alloc();
return hash ?: &global_hash;
futex_cleanup_hash()
scoped_guard(spinlock_irq, ¤t->sighand->siglock) {
hash = current->signal->futex_hash;
if (!hash || current->signal->nr_threads > 1)
return;
current->signal->futex_hash = NULL;
if (hash == &global_hash)
return;
}
kfree_rcu_mightsleep(hash);
Or something like that.
Thanks,
tglx
next prev parent reply other threads:[~2024-10-27 12:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-26 22:34 [RFC PATCH 0/3] futex: Add support task local hash maps Sebastian Andrzej Siewior
2024-10-26 22:34 ` [RFC PATCH 1/3] futex: Create helper function to initialize a hash slot Sebastian Andrzej Siewior
2024-10-26 22:34 ` [RFC PATCH 2/3] futex: Add basic infrastructure for local task local hash Sebastian Andrzej Siewior
2024-10-27 12:19 ` Thomas Gleixner [this message]
2024-10-28 10:30 ` Sebastian Andrzej Siewior
2024-10-28 10:58 ` Thomas Gleixner
2024-10-28 11:00 ` Peter Zijlstra
2024-10-28 12:02 ` Thomas Gleixner
2024-10-30 21:08 ` Peter Zijlstra
2024-10-30 23:14 ` Thomas Gleixner
2024-10-31 9:13 ` Peter Zijlstra
2024-10-28 10:16 ` Peter Zijlstra
2024-10-28 10:24 ` Sebastian Andrzej Siewior
2024-10-28 10:46 ` Peter Zijlstra
2024-10-28 13:10 ` Peter Zijlstra
2024-10-26 22:34 ` [RFC PATCH 3/3] futex: Use the task local hashmap Sebastian Andrzej Siewior
2024-10-28 10:22 ` Peter Zijlstra
2024-10-28 10:24 ` Sebastian Andrzej Siewior
2024-10-27 10:01 ` [RFC PATCH 0/3] futex: Add support task local hash maps Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cyjl4u1h.ffs@tglx \
--to=tglx@linutronix.de \
--cc=andrealmeid@igalia.com \
--cc=bigeasy@linutronix.de \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox