[External] [PATCH] riscv/futex: sign extend compare value in atomic cmpxchg

yunhui cui cuiyunhui at bytedance.com
Thu Feb 13 22:22:53 PST 2025


Hi Jess,

On Fri, Feb 14, 2025 at 2:05 PM Jessica Clarke <jrtc27 at jrtc27.com> wrote:
>
> On 14 Feb 2025, at 04:11, yunhui cui <cuiyunhui at bytedance.com> wrote:
> >
> > Hi,
> >
> > On Fri, Feb 14, 2025 at 2:31 AM <patchwork-bot+linux-riscv at kernel.org> wrote:
> >>
> >> Hello:
> >>
> >> This patch was applied to riscv/linux.git (fixes)
> >> by Palmer Dabbelt <palmer at rivosinc.com>:
> >>
> >> On Mon, 03 Feb 2025 11:06:00 +0100 you wrote:
> >>> Make sure the compare value in the lr/sc loop is sign extended to match
> >>> what lr.w does.  Fortunately, due to the compiler keeping the register
> >>> contents sign extended anyway the lack of the explicit extension didn't
> >>> result in wrong code so far, but this cannot be relied upon.
> >>>
> >>> Fixes: b90edb33010b ("RISC-V: Add futex support.")
> >>> Signed-off-by: Andreas Schwab <schwab at suse.de>
> >>>
> >>> [...]
> >>
> >> Here is the summary with links:
> >>  - riscv/futex: sign extend compare value in atomic cmpxchg
> >>    https://git.kernel.org/riscv/c/5c238584bce5
> >>
> >> You are awesome, thank you!
> >> --
> >> Deet-doot-dot, I am a bot.
> >> https://korg.docs.kernel.org/patchwork/pwbot.html
> >>
> >>
> >
> > I applied this patch, but it doesn't seem to take effect. There is no
> > sign extension for a2 in the assembly code. What did I miss?
> > GCC version >= 13.
> >
> > ffffffff800e87e0 <futex_atomic_cmpxchg_inatomic>:
> > ffffffff800e87e0: 1141                addi sp,sp,-16
> > ffffffff800e87e2: e422                sd s0,8(sp)
> > ffffffff800e87e4: 2bf01793          bseti a5,zero,0x3f
> > ffffffff800e87e8: 0800                addi s0,sp,16
> > ffffffff800e87ea: 17ed                addi a5,a5,-5
> > ffffffff800e87ec: 00b7f663          bgeu a5,a1,ffffffff800e87f8
> > <futex_atomic_cmpxchg_inatomic+0x18>
> > ffffffff800e87f0: 6422                ld s0,8(sp)
> > ffffffff800e87f2: 5549                li a0,-14
> > ffffffff800e87f4: 0141                addi sp,sp,16
> > ffffffff800e87f6: 8082                ret
> > ffffffff800e87f8: 872a                mv a4,a0
> > ffffffff800e87fa: 00040837          lui a6,0x40
> > ffffffff800e87fe: 10082073          csrs sstatus,a6
> > ffffffff800e8802: 4781                li a5,0
> > ffffffff800e8804: 1605a8af          lr.w.aqrl a7,(a1)
> > ffffffff800e8808: 00c89563          bne a7,a2,ffffffff800e8812
> > <futex_atomic_cmpxchg_inatomic+0x32>
> > ffffffff800e880c: 1ed5a52f          sc.w.aqrl a0,a3,(a1)
> > ffffffff800e8810: f975                bnez a0,ffffffff800e8804
> > <futex_atomic_cmpxchg_inatomic+0x24>
> > ffffffff800e8812: 0007851b          sext.w a0,a5
> > ffffffff800e8816: 10083073          csrc sstatus,a6
> > ffffffff800e881a: 01172023          sw a7,0(a4)
> > ffffffff800e881e: 6422                ld s0,8(sp)
> > ffffffff800e8820: 0141                addi sp,sp,16
> > ffffffff800e8822: 8082                ret
>
> The calling convention means a2 will be sign-extended on entry to the
> function, and since your compiler has not done anything to change the
> value that will still be true. So it has (legitimately) optimised out
> any sign extension as a no-op.

 If so, why this patch?

> Are you seeing any problems that you
> believe to be caused by this function, or are you just inspecting the
> disassembly to satisfy your own curiosity?

No actual problem traced here.


>
> > Should we do it like this:
> > __asm__ __volatile__ (
> > " sext.w %[ov], %[ov] \n"
> > ...
>
> No, it’s unnecessary and prevents optimisation.
>
> Jess
>
> > Thanks,
> > Yunhui
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>

Thanks,
Yunhui



More information about the linux-riscv mailing list