lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 16 Aug 2022 15:46:43 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     tytso@....edu, adilger.kernel@...ger.ca,
        linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Lukas Czerner <lczerner@...hat.com>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH] ext4: fix i_version handling in ext4

On Tue, Aug 16, 2022 at 09:43:16AM -0400, Jeff Layton wrote:
> On Tue, 2022-08-16 at 15:33 +0200, Christian Brauner wrote:
> > On Tue, Aug 16, 2022 at 09:15:22AM -0400, Jeff Layton wrote:
> > > ext4 currently updates the i_version counter when the atime is updated
> > > during a read. This is less than ideal as it can cause unnecessary cache
> > > invalidations with NFSv4. The increment in ext4_mark_iloc_dirty is also
> > > problematic since it can also corrupt the i_version counter for
> > > ea_inodes.
> > > 
> > > We aren't bumping the file times in ext4_mark_iloc_dirty, so changing
> > > the i_version there seems wrong, and is the cause of both problems.
> > > Remove that callsite and add increments to the setattr and setxattr
> > > codepaths (at the same time that we update the ctime). The i_version
> > > bump that already happens during timestamp updates should take care of
> > > the rest.
> > > 
> > > Cc: Lukas Czerner <lczerner@...hat.com>
> > > Cc: Jan Kara <jack@...e.cz>
> > > Cc: Christian Brauner <brauner@...nel.org>
> > > Signed-off-by: Jeff Layton <jlayton@...nel.org>
> > > ---
> > 
> > Seems good to me. But it seems that the xfs patch you sent does have
> > inode_inc_version() right after setattr_copy() as well. So I wonder if
> > we couldn't just try and move inode_inc_version() into setattr_copy()
> > itself.
> > 
> 
> We probably could, but setattr_copy has a lot of callers and most
> filesystems don't need this.  Also, there are some cases where we don't
> want to update the i_version after a setattr.
> 
> In particular, if you do a truncate and the size doesn't change, then
> you really don't want to update the timestamps (and therefore the
> i_version shouldn't change either).

We could probably all handle that with some massaging but I'm also fine
with doing it just for ext4 and xfs if these are the only ones where
this is relevant:

Reviewed-by: Christian Brauner (Microsoft) <brauner@...nel.org>

Powered by blists - more mailing lists