Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 22 Nov 2020 10:57:25 -0500 (EST)
From:   Xiaoli Feng <xifeng@redhat.com>
To:     "Darrick J. Wong" <darrick.wong@oracle.com>,
        Eric Sandeen <esandeen@redhat.com>
Cc:     Randy Dunlap <rdunlap@infradead.org>, linux-kernel@vger.kernel.org,
        ira weiny <ira.weiny@intel.com>,
        Xiaoli Feng <fengxiaoli0714@gmail.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Message-ID: <1450940377.59255884.1606060645520.JavaMail.zimbra@redhat.com>
In-Reply-To: <20201121011516.GD3837269@magnolia>
References: <20201121003331.21342-1-xifeng@redhat.com> <21890103-fce2-bb50-7fc2-6c6d509b982f@infradead.org> <20201121011516.GD3837269@magnolia>
Subject: Re: [PATCH] fs/stat: set attributes_mask for STATX_ATTR_DAX
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: fs/stat: set attributes_mask for STATX_ATTR_DAX
Thread-Index: UpJOH+7qV0HTw1EJ2RkbvKNCw/Hb9A==
Precedence: bulk

Hi,

Thanks for review.

----- Original Message -----
> From: "Darrick J. Wong" <darrick.wong@oracle.com>
> To: "XiaoLi Feng" <xifeng@redhat.com>
> Cc: "Randy Dunlap" <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, "ira weiny" <ira.weiny@intel.com>, "Xiaoli
> Feng" <fengxiaoli0714@gmail.com>, "linux-fsdevel" <linux-fsdevel@vger.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@gmail.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
> > 
> 
>