linux-kernel - Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 1 Dec 2020 18:29:26 -0800
From:   Ira Weiny <ira.weiny@...el.com>
To:     Eric Sandeen <sandeen@...deen.net>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Chinner <david@...morbit.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Eric Sandeen <sandeen@...hat.com>,
        Miklos Szeredi <mszeredi@...hat.com>,
        David Howells <dhowells@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-man <linux-man@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        xfs <linux-xfs@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Xiaoli Feng <xifeng@...hat.com>
Subject: Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to
 filesystems

On Tue, Dec 01, 2020 at 04:26:43PM -0600, Eric Sandeen wrote:
> On 12/1/20 4:12 PM, Linus Torvalds wrote:
> > On Tue, Dec 1, 2020 at 2:03 PM Eric Sandeen <sandeen@...deen.net> wrote:
> >>
> >> That's why I was keen to just add DAX unconditionally at this point, and if we want
> >> to invent/refine meanings for the mask, we can still try to do that?
> > 
> > Oh Gods.  Let's *not* make this some "random filesystem choice" where
> > now semantics depends on what some filesystem decided to do, and
> > different filesystems have very subtly different semantics.
> 
> Well, I had hoped that refinement might start with the interface
> documentation, I'm certainly not suggesting every filesystem should go
> its own way.
> > This all screams "please keep this in the VFS layer" so that we at
> > least have _one_ place where these kinds of decisions are made.
> 
> Making the "right decision" depends on what the mask actually means,
> I guess.
> 
> Today we set a DAX attribute in statx which is not set in the mask.
> That seems clearly broken.

Yes...  and no.  You can't set the statx DAX flag directly.  It is only an
indicator of the current file state.  That state is affected by the
inode mode and the DAX mount option.

But I agree that having a bit set when the corresponding mask is 0 is odd.

> 
> We can either leave that as it is, set DAX in the mask for everyone in
> the VFS, or delegate that mask-setting task to the individual filesystems
> so that it reflects <something>, probably "can this inode ever be in dax
> mode?"
> 
> I honestly don't care if we keep setting the attribute itself in the VFS;
> if that's the right thing to do, that's fine.  (If so, it seems like
> IS_IMMUTABLE -> STATX_ATTR_IMMUTABLE etc could be moved there, too.)

The reason I put it in the VFS layer was that the statx was intended to be a
VFS indication of the state of the inode.  This differs from the FS_XFLAG_DAX
which is a state of the on-disk inode.  The VFS IS_DAX can be altered by the
mount option forcing DAX or no-DAX.

So there was a reason for having it at that level.

But it is true that only FS's which support DAX will ever set IS_DAX() and
having the attribute set near the mask probably makes the code a bit more
clear.

So I'm not opposed to the patch either.  But users can't ever set the flag
directly so I'm not sure if it being in the mask is going to confuse anyone.

Ira

> 
> -Eric