All of lore.kernel.org
 help / color / mirror / Atom feed
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: [PATCH v5 07/14] futex: Move the retry_private label.
Date: Mon, 16 Dec 2024 21:41:42 +0100	[thread overview]
Message-ID: <87ttb3743d.ffs@tglx> (raw)
In-Reply-To: <20241215230642.104118-8-bigeasy@linutronix.de>

On Mon, Dec 16 2024 at 00:00, Sebastian Andrzej Siewior wrote:
> The label futex_requeue in futex_requeue() and futex_wake_op() is jumped
> after the lock is dropped in a retry operation.

The label is jumped? 

> This assumes that the hb does not need to be hashed again. If hb is
> resized then the hb can change if the reference is dropped.

Again 'hb' and the confusion of hash bucket (hb) resize.

> Move the retry_private label before the hashing operation.

The overall explanation is not really comprehensible.

    futex: Re-evaluate the hash bucket after dropping the lock

     Sebastian Andrzej Siewior wrote:

     In futex_requeue() and futex_wake_op() the hash bucket lock is
     dropped in the failure paths for handling page faults and other
     error scenarios. After that the code jumps back to retry_private
     which relocks the hash bucket[s] under the assumption that the hash
     bucket pointer which was retrieved via futex_hash() is still valid.
     
     With resizable private hash buckets, that assumption is not longer
     true as the waiters can be moved to a larger hash in the meantime.

     Move the retry_private label above the hashing function to handle
     this correctly.

Or so.

Thanks,

        tglx

  reply	other threads:[~2024-12-16 20:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-15 23:00 [PATCH v5 0/14] futex: Add support task local hash maps Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 01/14] futex: Create helper function to initialize a hash slot Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 02/14] futex: Add basic infrastructure for local task local hash Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 03/14] futex: Allow automatic allocation of process wide futex hash Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 04/14] futex: Hash only the address for private futexes Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 05/14] futex: Move private hashing into its own function Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 06/14] futex: Add helper which include the put of a hb after end of operation Sebastian Andrzej Siewior
2024-12-16 18:48   ` Thomas Gleixner
2024-12-17 17:07     ` Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 07/14] futex: Move the retry_private label Sebastian Andrzej Siewior
2024-12-16 20:41   ` Thomas Gleixner [this message]
2024-12-15 23:00 ` [PATCH v5 08/14] futex: Introduce futex_get_locked_hb() Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 09/14] futex: Allow to re-allocate the private hash bucket Sebastian Andrzej Siewior
2024-12-17 14:58   ` Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 10/14] futex: Resize futex hash table based on number of threads Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 11/14] futex: Use a hashmask instead of hashsize Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 12/14] tools/perf: Add the prctl(PR_FUTEX_HASH,…) to futex-hash Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 13/14] tools/perf: The the current affinity for CPU pinning in futex-hash Sebastian Andrzej Siewior
2024-12-15 23:00 ` [PATCH v5 14/14] 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=87ttb3743d.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.