From: Jeff Layton <jlayton@kernel.org>
To: Andreas Schwab <schwab@suse.de>, linux-riscv@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: Multigrain timestamps do not work on RISC-V
Date: Wed, 29 Jan 2025 18:28:36 -0500 [thread overview]
Message-ID: <fe719cdf52e9fc48955f116ea2e23ea8136e4d87.camel@kernel.org> (raw)
In-Reply-To: <f704b0c40c393d1c326f13d043505960924f879a.camel@kernel.org>
On Wed, 2025-01-29 at 18:06 -0500, Jeff Layton wrote:
> On Wed, 2025-01-29 at 18:20 +0100, Andreas Schwab wrote:
> > On Jan 29 2025, Andreas Schwab wrote:
> >
> > > My guess would be that something in inode_set_ctime_current is going
> > > wrong.
> >
> > The bug is in the arch_cmpxchg macros in <asm/cmpxchg.h>, they mishandle
> > atomic exchange of u32 values:
> >
> > # fs/inode.c:2802: if (cns == now.tv_nsec && inode->i_ctime_sec == now.tv_sec) {
> > #NO_APP
> > ld a5,-96(s0) # _33, now.tv_nsec
> > # fs/inode.c:2802: if (cns == now.tv_nsec && inode->i_ctime_sec == now.tv_sec) {
> > slli a4,s2,32 #, _49, cns
> > srli a4,a4,32 #, _49, _49
> > # fs/inode.c:2802: if (cns == now.tv_nsec && inode->i_ctime_sec == now.tv_sec) {
> > beq a4,a5,.L1248 #, _49, _33,
> > .L1205:
> > addi a3,s1,120 #, __ai_ptr, inode
> > .L1221:
> > # fs/inode.c:2809: if (try_cmpxchg(&inode->i_ctime_nsec, &cur, now.tv_nsec)) {
> > #APP
> > # 2809 "fs/inode.c" 1
> > 0: lr.w a2, 0(a3) # __ret, *__ai_ptr_20
> > bne a2, a4, 1f # __ret, _49
> >
> > Here the unsigned extended value of cur (a4) is compared with the sign
> > extended value of inode->i_ctime_nsec (a2). They cannot match if cur
> > has I_CTIME_QUERIED set (the sign bit). The lr/sc loop is exited before
> > the store conditional is executed.
> >
> > sc.w.rl a1, a5, 0(a3) # __rc, _33, *__ai_ptr_20
> > bnez a1, 0b # __rc
> > fence rw,rw
> > 1:
> >
> > # 0 "" 2
> > #NO_APP
> > sext.w a5,a2 # __ret, __ret
> >
> > A redundant sign extension of the current contents of inode->i_ctime_nsec.
> >
> > # fs/inode.c:2809: if (try_cmpxchg(&inode->i_ctime_nsec, &cur, now.tv_nsec)) {
> > bne a5,s2,.L1211 #, __ret, cns,
> >
> > Here the sign extended value of inode->i_ctime_nsec (a5) is compared
> > with the sign extended expected value (s2). They match, and try_cmpxchg
> > returns true, but the store never happend.
> >
>
> Wow, nice catch! Had me worried there for a bit!
>
For the record:
Bit 30 is also unused. When I wrote these patches, I considered using
that instead of the sign bit since I wasn't sure whether I might run
into problems using the sign bit.
Obviously, fixing the macro seems like the better solution, but if
fixing this efficiently is a problem, then moving I_CTIME_QUERIED to
bit 30 is also an option.
Cheers,
--
Jeff Layton <jlayton@kernel.org>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Layton <jlayton@kernel.org>
To: Andreas Schwab <schwab@suse.de>, linux-riscv@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: Multigrain timestamps do not work on RISC-V
Date: Wed, 29 Jan 2025 18:28:36 -0500 [thread overview]
Message-ID: <fe719cdf52e9fc48955f116ea2e23ea8136e4d87.camel@kernel.org> (raw)
In-Reply-To: <f704b0c40c393d1c326f13d043505960924f879a.camel@kernel.org>
On Wed, 2025-01-29 at 18:06 -0500, Jeff Layton wrote:
> On Wed, 2025-01-29 at 18:20 +0100, Andreas Schwab wrote:
> > On Jan 29 2025, Andreas Schwab wrote:
> >
> > > My guess would be that something in inode_set_ctime_current is going
> > > wrong.
> >
> > The bug is in the arch_cmpxchg macros in <asm/cmpxchg.h>, they mishandle
> > atomic exchange of u32 values:
> >
> > # fs/inode.c:2802: if (cns == now.tv_nsec && inode->i_ctime_sec == now.tv_sec) {
> > #NO_APP
> > ld a5,-96(s0) # _33, now.tv_nsec
> > # fs/inode.c:2802: if (cns == now.tv_nsec && inode->i_ctime_sec == now.tv_sec) {
> > slli a4,s2,32 #, _49, cns
> > srli a4,a4,32 #, _49, _49
> > # fs/inode.c:2802: if (cns == now.tv_nsec && inode->i_ctime_sec == now.tv_sec) {
> > beq a4,a5,.L1248 #, _49, _33,
> > .L1205:
> > addi a3,s1,120 #, __ai_ptr, inode
> > .L1221:
> > # fs/inode.c:2809: if (try_cmpxchg(&inode->i_ctime_nsec, &cur, now.tv_nsec)) {
> > #APP
> > # 2809 "fs/inode.c" 1
> > 0: lr.w a2, 0(a3) # __ret, *__ai_ptr_20
> > bne a2, a4, 1f # __ret, _49
> >
> > Here the unsigned extended value of cur (a4) is compared with the sign
> > extended value of inode->i_ctime_nsec (a2). They cannot match if cur
> > has I_CTIME_QUERIED set (the sign bit). The lr/sc loop is exited before
> > the store conditional is executed.
> >
> > sc.w.rl a1, a5, 0(a3) # __rc, _33, *__ai_ptr_20
> > bnez a1, 0b # __rc
> > fence rw,rw
> > 1:
> >
> > # 0 "" 2
> > #NO_APP
> > sext.w a5,a2 # __ret, __ret
> >
> > A redundant sign extension of the current contents of inode->i_ctime_nsec.
> >
> > # fs/inode.c:2809: if (try_cmpxchg(&inode->i_ctime_nsec, &cur, now.tv_nsec)) {
> > bne a5,s2,.L1211 #, __ret, cns,
> >
> > Here the sign extended value of inode->i_ctime_nsec (a5) is compared
> > with the sign extended expected value (s2). They match, and try_cmpxchg
> > returns true, but the store never happend.
> >
>
> Wow, nice catch! Had me worried there for a bit!
>
For the record:
Bit 30 is also unused. When I wrote these patches, I considered using
that instead of the sign bit since I wasn't sure whether I might run
into problems using the sign bit.
Obviously, fixing the macro seems like the better solution, but if
fixing this efficiently is a problem, then moving I_CTIME_QUERIED to
bit 30 is also an option.
Cheers,
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-01-29 23:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 10:07 Multigrain timestamps do not work on RISC-V Andreas Schwab
2025-01-29 10:07 ` Andreas Schwab
2025-01-29 17:20 ` Andreas Schwab
2025-01-29 17:20 ` Andreas Schwab
2025-01-29 23:06 ` Jeff Layton
2025-01-29 23:06 ` Jeff Layton
2025-01-29 23:28 ` Jeff Layton [this message]
2025-01-29 23:28 ` Jeff Layton
2025-01-30 9:29 ` Andreas Schwab
2025-01-30 9:29 ` Andreas Schwab
2025-01-29 23:03 ` Jeff Layton
2025-01-29 23:03 ` Jeff Layton
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=fe719cdf52e9fc48955f116ea2e23ea8136e4d87.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=schwab@suse.de \
/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.