linux-kernel - Re: [RFC PATCH] common/rc: Fix _check_s

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] [day] [month] [year] [list]

Date:   Wed, 2 Dec 2020 11:08:23 -0800
From:   Ira Weiny <ira.weiny@...el.com>
To:     Eric Sandeen <sandeen@...deen.net>
Cc:     fstests@...r.kernel.org, linux-kernel@...r.kernel.org,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Dave Chinner <david@...morbit.com>,
        Christoph Hellwig <hch@....de>,
        "Theodore Y. Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>,
        Jeff Moyer <jmoyer@...hat.com>, linux-ext4@...r.kernel.org,
        linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Eric Sandeen <sandeen@...hat.com>,
        David Howells <dhowells@...hat.com>
Subject: Re: [RFC PATCH] common/rc: Fix _check_s_dax() for kernel 5.10

On Wed, Dec 02, 2020 at 11:10:50AM -0600, Eric Sandeen wrote:
> On 12/2/20 10:07 AM, ira.weiny@...el.com wrote:
> > From: Ira Weiny <ira.weiny@...el.com>
> > 
> > There is a conflict with the user visible statx bits 'mount root' and
> > 'dax'.  The kernel is shifting the dax bit.[1]
> > 
> > Adjust _check_s_dax() to use the new bit.
> > 
> > [1] https://lore.kernel.org/lkml/3e28d2c7-fbe5-298a-13ba-dcd8fd504666@redhat.com/
> > 
> > Signed-off-by: Ira Weiny <ira.weiny@...el.com>
> > 
> > ---
> > 
> > I'm not seeing an easy way to check for kernel version.  It seems like that is
> > the right thing to do.  So do I need to do that by hand or is that something
> > xfstests does not worry about?
> 
> xfstests gets used on distro kernels too, so relying on kernel version isn't
> really something we can use to make determinations like this, unfortunately.
> 
> Probably the best we can do is hope that the change makes it to stable and
> distro kernels quickly, and the old flag fades into obscurity.
> 
> Maybe worth a comment in the test mentioning the SNAFU, though, for anyone
> investigating it when it fails on older kernels?

Good idea.

> 
> > Ira
> > 
> > ---
> >  common/rc | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/common/rc b/common/rc
> > index b5a504e0dcb4..3d45e233954f 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -3222,9 +3222,9 @@ _check_s_dax()
> >  
> >  	local attributes=$($XFS_IO_PROG -c 'statx -r' $target | awk '/stat.attributes / { print $3 }')
> >  	if [ $exp_s_dax -eq 0 ]; then
> > -		(( attributes & 0x2000 )) && echo "$target has unexpected S_DAX flag"
> > +		(( attributes & 0x00200000 )) && echo "$target has unexpected S_DAX flag"
> >  	else
> > -		(( attributes & 0x2000 )) || echo "$target doesn't have expected S_DAX flag"
> > +		(( attributes & 0x00200000 )) || echo "$target doesn't have expected S_DAX flag"
> 
> I suppose you could add a test for 0x2000 in this failure case, and echo "Is your kernel missing
> commit xxxxxx?" as another hint.

Yea, I think that is ok since the test should not be running on any root mount
points.

V2 will come after the patch is merged.

Ira