linux-kernel - Re: [PATCH] fs/stat: set attributes_mask for STATX_ATTR

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]

Message-ID: <1450940377.59255884.1606060645520.JavaMail.zimbra@redhat.com>
Date:   Sun, 22 Nov 2020 10:57:25 -0500 (EST)
From:   Xiaoli Feng <xifeng@...hat.com>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Eric Sandeen <esandeen@...hat.com>
Cc:     Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org,
        ira weiny <ira.weiny@...el.com>,
        Xiaoli Feng <fengxiaoli0714@...il.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] fs/stat: set attributes_mask for STATX_ATTR_DAX

Hi,

Thanks for review.

----- Original Message -----
> From: "Darrick J. Wong" <darrick.wong@...cle.com>
> To: "XiaoLi Feng" <xifeng@...hat.com>
> Cc: "Randy Dunlap" <rdunlap@...radead.org>, linux-kernel@...r.kernel.org, "ira weiny" <ira.weiny@...el.com>, "Xiaoli
> Feng" <fengxiaoli0714@...il.com>, "linux-fsdevel" <linux-fsdevel@...r.kernel.org>
> Sent: Saturday, November 21, 2020 10:03:18 AM
> Subject: Re: [PATCH] fs/stat: set attributes_mask for STATX_ATTR_DAX
> 
> [Adding fsdevel to cc since this is a filesystems question]
> 
> On Fri, Nov 20, 2020 at 04:58:09PM -0800, Randy Dunlap wrote:
> > Hi,
> > 
> > I don't know this code, but:
> > 
> > On 11/20/20 4:33 PM, XiaoLi Feng wrote:
> > > From: Xiaoli Feng <fengxiaoli0714@...il.com>
> > > 
> > > keep attributes and attributes_mask are consistent for
> > > STATX_ATTR_DAX.
> > > ---
> > >  fs/stat.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/fs/stat.c b/fs/stat.c
> > > index dacecdda2e79..914a61d256b0 100644
> > > --- a/fs/stat.c
> > > +++ b/fs/stat.c
> > > @@ -82,7 +82,7 @@ int vfs_getattr_nosec(const struct path *path, struct
> > > kstat *stat,
> > >  
> > >  	if (IS_DAX(inode))
> > >  		stat->attributes |= STATX_ATTR_DAX;
> > > -
> > > +	stat->attributes_mask |= STATX_ATTR_DAX;
> > 
> > Why shouldn't that be:
> > 
> > 	if (IS_DAX(inode))
> > 		stat->attributes_mask |= STATX_ATTR_DAX;
> > 
> > or combine them, like this:
> > 
> > 	if (IS_DAX(inode)) {
> > 		stat->attributes |= STATX_ATTR_DAX;
> > 		stat->attributes_mask |= STATX_ATTR_DAX;
> > 	}
> > 
> > 
> > and no need to delete that blank line.
> 
> Some filesystems could support DAX but not have it enabled for this
> particular file, so this won't work.
> 
> General question: should filesystems that are /capable/ of DAX signal
> this by setting the DAX bit in the attributes mask?  Or is this a VFS
> feature and hence here is the appropriate place to be setting the mask?

Actually I just see here set the attributes. Then set the attributes mask 
after it.

> 
> Extra question: should we only set this in the attributes mask if
> CONFIG_FS_DAX=y ?

No, my origin patch always set this attributes mask. It's out of if condition.

        if (IS_DAX(inode))
                stat->attributes |= STATX_ATTR_DAX;
-
+       stat->attributes_mask |= STATX_ATTR_DAX;


> 
> --D
> 
> > >  	if (inode->i_op->getattr)
> > >  		return inode->i_op->getattr(path, stat, request_mask,
> > >  					    query_flags);
> > > 
> > 
> > thanks.
> > --
> > ~Randy
> > 
> 
>