linux-ext4 - Re: [PATCH v4 4/9] nfsd: ensure we use ctime_peek to grab the inode->i

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 18 May 2023 11:31:45 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Chuck Lever III <chuck.lever@...cle.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>,
        Amir Goldstein <amir73il@...il.com>,
        David Howells <dhowells@...hat.com>,
        Neil Brown <neilb@...e.de>,
        Matthew Wilcox <willy@...radead.org>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Theodore T'so <tytso@....edu>, Chris Mason <clm@...com>,
        Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>,
        Namjae Jeon <linkinjeon@...nel.org>,
        Steve French <sfrench@...ba.org>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Tom Talpey <tom@...pey.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Linux-XFS <linux-xfs@...r.kernel.org>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        "linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>
Subject: Re: [PATCH v4 4/9] nfsd: ensure we use ctime_peek to grab the
 inode->i_ctime

On Thu, 2023-05-18 at 13:43 +0000, Chuck Lever III wrote:
> 
> > On May 18, 2023, at 7:47 AM, Jeff Layton <jlayton@...nel.org> wrote:
> > 
> > If getattr fails, then nfsd can end up scraping the time values directly
> > out of the inode for pre and post-op attrs. This may or may not be the
> > right thing to do, but for now make it at least use ctime_peek in this
> > situation to ensure that the QUERIED flag is masked.
> 
> That code comes from:
> 
> commit 39ca1bf624b6b82cc895b0217889eaaf572a7913
> Author:     Amir Goldstein <amir73il@...il.com>
> AuthorDate: Wed Jan 3 17:14:35 2018 +0200
> Commit:     J. Bruce Fields <bfields@...hat.com>
> CommitDate: Thu Feb 8 13:40:17 2018 -0500
> 
>     nfsd: store stat times in fill_pre_wcc() instead of inode times
> 
>     The time values in stat and inode may differ for overlayfs and stat time
>     values are the correct ones to use. This is also consistent with the fact
>     that fill_post_wcc() also stores stat time values.
> 
>     This means introducing a stat call that could fail, where previously we
>     were just copying values out of the inode.  To be conservative about
>     changing behavior, we fall back to copying values out of the inode in
>     the error case.  It might be better just to clear fh_pre_saved (though
>     note the BUG_ON in set_change_info).
> 
>     Signed-off-by: Amir Goldstein <amir73il@...il.com>
>     Signed-off-by: J. Bruce Fields <bfields@...hat.com>
> 
> I was thinking it might have been added to handle odd corner
> cases around re-exporting NFS mounts, but that does not seem
> to be the case.
> 
> The fh_getattr() can fail for legitimate reasons -- like the
> file is in the middle of being deleted or renamed over -- I
> would think. This code should really deal with that by not
> adding pre-op attrs, since they are optional.
> 

That sounds fine to me. I'll plan to drop this patch from the series and
I'll send a separate patch to just remove those branches altogether
(which should DTRT).

-- 
Jeff Layton <jlayton@...nel.org>