All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Alex <alex.fcyrx@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	brauner@kernel.org, jack@suse.cz, torvalds@linux-foundation.org,
	paulmck@kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fs: Remove obsolete logic in i_size_read/write
Date: Wed, 16 Jul 2025 14:57:45 +0100	[thread overview]
Message-ID: <aHev2X8439xaamsX@casper.infradead.org> (raw)
In-Reply-To: <CAKawSAkQd_V9wJn6fiQQWVguTB0e7vDNnQqjuZRUZ1VwzXuvog@mail.gmail.com>

On Wed, Jul 16, 2025 at 09:44:31PM +0800, Alex wrote:
> On Wed, Jul 16, 2025 at 9:41 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Wed, Jul 16, 2025 at 09:28:29PM +0800, Alex wrote:
> > > On Wed, Jul 16, 2025 at 9:12 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > > >
> > > > On Wed, Jul 16, 2025 at 08:53:04PM +0800, Alex wrote:
> > > > > The logic is used to protect load/store tearing on 32 bit platforms,
> > > > > for example, after i_size_read returned, there is no guarantee that
> > > > > inode->size won't be changed. Therefore, READ/WRITE_ONCE suffice, which
> > > > > is already implied by smp_load_acquire/smp_store_release.
> > > >
> > > > Sorry, what?  The problem is not a _later_ change, it's getting the
> > > > upper and lower 32bit halves from different values.
> > > >
> > > > Before: position is 0xffffffff
> > > > After: position is 0x100000000
> > > > The value that might be returned by your variant: 0x1ffffffff.
> > >
> > > I mean the sequence lock here is used to only avoid load/store tearing,
> > > smp_load_acquire/smp_store_release already protects that.
> >
> > Why do you think that?  You're wrong, but it'd be useful to understand
> > what misled you into thinking that.
> 
> smp_load_acquire/smp_store_release implies READ_ONCE/WRITE_ONCE,
> and READ_ONCE/WRITE_ONCE avoid load/store tearing.
> 
> What am I missing here?

They only avoid tearing for sizes <= word size.  If you have a 32-bit
CPU, they cannot avoid tearing for 64-bit loads/stores.

  reply	other threads:[~2025-07-16 13:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-16 12:53 [PATCH] fs: Remove obsolete logic in i_size_read/write Alex
2025-07-16 13:12 ` Al Viro
2025-07-16 13:28   ` Alex
2025-07-16 13:41     ` Matthew Wilcox
2025-07-16 13:44       ` Alex
2025-07-16 13:57         ` Matthew Wilcox [this message]
2025-07-16 14:38           ` Alex
2025-07-17  5:05 ` kernel test robot

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=aHev2X8439xaamsX@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=alex.fcyrx@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.