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  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:   Mon, 25 May 2020 09:28:44 +0200
From:   Jan Kara <>
To:     Ira Weiny <>
Cc:     Jan Kara <>,,
        Andreas Dilger <>,
        "Theodore Y. Ts'o" <>,
        Eric Biggers <>,
        Al Viro <>,
        Dan Williams <>,
        Dave Chinner <>,
        Christoph Hellwig <>, Jeff Moyer <>,
        "Darrick J. Wong" <>,,
Subject: Re: [PATCH V4 7/8] fs/ext4: Introduce DAX inode flag

On Sun 24-05-20 21:39:10, Ira Weiny wrote:
> On Fri, May 22, 2020 at 01:48:48PM +0200, Jan Kara wrote:
> > And then we should check conflicts with the journal flag as well, as I
> > mentioned in reply to the first patch. There it is more complicated by the
> > fact that we should disallow setting of both EXT4_INODE_DAX_FL and
> > EXT4_JOURNAL_DATA_FL at the same time so the checks will be somewhat more
> > complicated.
> I'm confused by jflag.  Why is EXT4_JOURNAL_DATA_FL stored in jflag?

It isn't just EXT4_JOURNAL_DATA_FL. It is:

	jflag = flags & EXT4_JOURNAL_DATA_FL;

so it is EXT4_JOURNAL_DATA_FL if it should be set by the current ioctl and 0
otherwise. But I agree that since we mostly do

	(jflag ^ oldflags) & EXT4_JOURNAL_DATA_FL

jflags is mostly useless as we could do just

	(flags ^ oldflags) & EXT4_JOURNAL_DATA_FL

I guess it's mostly a relict from the past...

Jan Kara <>

Powered by blists - more mailing lists