All of 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: 6+ 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]
2026-06-16 18:36       ` Catalin Marinas

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 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.