All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, Yeoreum Yun <yeoreum.yun@arm.com>
Subject: Re: [PATCH] arm64: futex: Consolidate 'old == new' check in __lsui_cmpxchg32()
Date: Tue, 19 May 2026 16:09:02 +0100	[thread overview]
Message-ID: <agx9DmAbHdAoSlWU@arm.com> (raw)
In-Reply-To: <20260519090823.7216-1-will@kernel.org>

On Tue, May 19, 2026 at 10:08:22AM +0100, Will Deacon wrote:
> The LSUI futex implementation relies on a cmpxchg() loop to implement
> FUTEX_OP_XOR, as the architecture doesn't provide unprivileged *EOR
> atomics. Since the unprivileged 'CAST' instructions used to implement
> the cmpxchg() can only operate on 64-bit memory locations, the
> __lsui_cmpxchg32() helper function performs a song and dance to marshall
> the 32-bit futex value into the correct part of a 64-bit register and
> fill the remaining bytes with the neighbouring data.

IIRC, the reason for the current __lsui_cmpxchg32() was not EOR but the
expected futex_atomic_cmpxchg_inatomic() semantics. Looking at it again,
we have wake_futex_pi() that does something else if the ret is 0 but the
value differs. Looking at it again, the caller of wake_futex_pi()
retries on -EAGAIN anyway, so I don't see a correctness issue, it will
eventually hit the condition.

(Sashiko complains about the change but I think we can ignore it)

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>


  parent reply	other threads:[~2026-05-19 15:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19  9:08 [PATCH] arm64: futex: Consolidate 'old == new' check in __lsui_cmpxchg32() Will Deacon
2026-05-19  9:24 ` Yeoreum Yun
2026-05-19 15:09 ` Catalin Marinas [this message]
2026-06-02 14:19   ` Will Deacon

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=agx9DmAbHdAoSlWU@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=will@kernel.org \
    --cc=yeoreum.yun@arm.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.