From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org,
"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>
Subject: Re: [PATCH v4 06/11] futex: Allow to re-allocate the private hash bucket.
Date: Thu, 12 Dec 2024 17:16:48 +0100 [thread overview]
Message-ID: <20241212161648.W97qL77l@linutronix.de> (raw)
In-Reply-To: <8734ivcgx7.ffs@tglx>
On 2024-12-10 23:27:32 [+0100], Thomas Gleixner wrote:
> On Tue, Dec 03 2024 at 17:42, Sebastian Andrzej Siewior wrote:
> > +static void futex_put_old_hb_p(struct futex_hash_bucket_private *hb_p)
> > +{
> > + unsigned int slots = hb_p->hash_mask + 1;
> > + struct futex_hash_bucket *hb;
> > + DEFINE_WAKE_Q(wake_q);
> > + unsigned int i;
> > +
> > + for (i = 0; i < slots; i++) {
> > + struct futex_q *this;
> > +
> > + hb = &hb_p->queues[i];
> > +
> > + spin_lock(&hb->lock);
> > + plist_for_each_entry(this, &hb->chain, list)
> > + wake_q_add(&wake_q, this->task);
> > + spin_unlock(&hb->lock);
> > + }
> > + futex_hash_priv_put(hb_p);
> > +
> > + wake_up_q(&wake_q);
>
> So you wake up all queued waiters and let themself requeue on the new
> hash.
>
> How is that safe against the following situation:
>
> CPU 0 CPU 1
> hb_p_old = mm->futex_hash_bucket; hbp = mm->futex_hash_bucket;
> mm->futex_hash_bucket = new;
> // Referrence count succeeds!
> rcuref_get(&hpb->refcnt);
> futex_put_old_hb_p();
> // Queues on old hash and
> // is lost forever
> queue(hbp);
This does not happen. futex_q_lock() check if the hb is valid after
locking the HB it obtained. So if the HB is still valid then
futex_put_old_hb_p() will see/ wake it. If it is not then it will drop
the lock and try again.
However looking at your proposal below, it has some benefits. Let me
implement this instead.
Sebastian
next prev parent reply other threads:[~2024-12-12 16:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 16:42 [PATCH v4 0/11] futex: Add support task local hash maps Sebastian Andrzej Siewior
2024-12-03 16:42 ` [PATCH v4 01/11] futex: Create helper function to initialize a hash slot Sebastian Andrzej Siewior
2024-12-10 15:13 ` Thomas Gleixner
2024-12-03 16:42 ` [PATCH v4 02/11] futex: Add basic infrastructure for local task local hash Sebastian Andrzej Siewior
2024-12-10 15:23 ` Thomas Gleixner
2024-12-03 16:42 ` [PATCH v4 03/11] futex: Allow automatic allocation of process wide futex hash Sebastian Andrzej Siewior
2024-12-10 16:07 ` Thomas Gleixner
2024-12-03 16:42 ` [PATCH v4 04/11] futex: Hash only the address for private futexes Sebastian Andrzej Siewior
2024-12-03 16:42 ` [PATCH v4 05/11] futex: Track the futex hash bucket Sebastian Andrzej Siewior
2024-12-10 18:45 ` Thomas Gleixner
2024-12-12 16:41 ` Sebastian Andrzej Siewior
2024-12-03 16:42 ` [PATCH v4 06/11] futex: Allow to re-allocate the private " Sebastian Andrzej Siewior
2024-12-10 22:27 ` Thomas Gleixner
2024-12-11 14:32 ` Thomas Gleixner
2024-12-11 15:22 ` Thomas Gleixner
2024-12-12 16:16 ` Sebastian Andrzej Siewior [this message]
2024-12-03 16:42 ` [PATCH v4 07/11] futex: Allow to make the number of slots invariant Sebastian Andrzej Siewior
2024-12-06 8:19 ` Sebastian Andrzej Siewior
2024-12-03 16:42 ` [PATCH v4 08/11] futex: Resize futex hash table based on number of threads Sebastian Andrzej Siewior
2024-12-06 9:27 ` Thomas Gleixner
2024-12-03 16:42 ` [PATCH v4 09/11] tools/perf: Add the prctl(PR_FUTEX_HASH,…) to futex-hash Sebastian Andrzej Siewior
2024-12-03 16:42 ` [PATCH v4 10/11] tools/perf: The the current affinity for CPU pinning in futex-hash Sebastian Andrzej Siewior
2024-12-03 16:42 ` [PATCH v4 11/11] tools/perf: Allocate futex locks on the local CPU-node Sebastian Andrzej Siewior
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=20241212161648.W97qL77l@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=andrealmeid@igalia.com \
--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=tglx@linutronix.de \
--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
all inboxes | Powered by JetHome®