Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: futex: Consolidate 'old == new' check in __lsui_cmpxchg32()
Date: Tue, 16 Jun 2026 10:26:59 +0100	[thread overview]
Message-ID: <ajEW41-ncVO_nDY7@e129823.arm.com> (raw)
In-Reply-To: <ah7md1ha86Anr7nb@willie-the-truck>

> On Tue, May 19, 2026 at 04:09:02PM +0100, Catalin Marinas wrote:
> > 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.
> 
> Hmm, but I think that means my patch does change the behaviour of
> wake_futex_pi() in an undesirable way. For example, futex_unlock_pi()
> will go round the retry loop for any change in the futex value, whereas
> before we would go back to userspace only if the TID changed.
> 
> So I think we should swallow the -EAGAIN for the CAS-based cmpxchg() if
> the futex word has changed, along the lines of the diff below.
> 
> Will
> 
> --->8
> 
> diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
> index db84a7b2de74..79c6d86c38a9 100644
> --- a/arch/arm64/include/asm/futex.h
> +++ b/arch/arm64/include/asm/futex.h
> @@ -215,14 +215,14 @@ __lsui_futex_atomic_eor(int oparg, u32 __user *uaddr, int *oval)
>  static __always_inline int
>  __lsui_futex_cmpxchg(u32 __user *uaddr, u32 oldval, u32 newval, u32 *oval)
>  {
> +       u32 curval = oldval;
>         int ret;
>  
> -       /*
> -        * Callers of futex_atomic_cmpxchg_inatomic() already retry on
> -        * -EAGAIN, no need for another loop of max retries.
> -        */
> -       ret = __lsui_cmpxchg32(uaddr, &oldval, newval);
> -       *oval = oldval;
> +       ret = __lsui_cmpxchg32(uaddr, &curval, newval);
> +       if (ret == -EAGAIN && curval != oldval)
> +               ret = 0;
> +
> +       *oval = curval;
>         return ret;
>  }
>  #endif /* CONFIG_ARM64_LSUI */

Agree. It is good that this additional patch does not change
the existing behavior.

@Catalin, Could you check this please?

Thanks!

-- 
Sincerely,
Yeoreum Yun


      reply	other threads:[~2026-06-16  9:27 UTC|newest]

Thread overview: 5+ 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
2026-06-02 14:19   ` Will Deacon
2026-06-16  9:26     ` Yeoreum Yun [this message]

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