linux-ext4 - Re: [PATCH 0/3] ext2, ext4, xfs: hard fail dax mount on unsupported devices

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAPcyv4iAD_wkjY1way1rOxr4=gC_TGx71VquF13ooAuUPz9RJw@mail.gmail.com>
Date:   Thu, 11 Oct 2018 11:08:26 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jan Kara <jack@...e.cz>
Cc:     Eric Sandeen <sandeen@...deen.net>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        linux-ext4 <linux-ext4@...r.kernel.org>, zwisler@...nel.org
Subject: Re: [PATCH 0/3] ext2, ext4, xfs: hard fail dax mount on unsupported devices

On Thu, Oct 11, 2018 at 3:37 AM Jan Kara <jack@...e.cz> wrote:
>
> On Mon 08-10-18 14:32:46, Eric Sandeen wrote:
> > In response to an earlier xfs patch to change how xfs reacts to
> > dax incompatibilities, Dave said:
> >
> > > I suspect we need to be more harsh are rejecting mounts with -o dax
> > > on devices DAX isn't supported on. This mount option is going into
> > > production systems - it's not just for "testing" as the comments all
> > > claim. i Things will break in production systems if DAX isn't
> > > enabled and they are expecting it to be enabled.
> >
> > and I tend to agree, so proposing this change to hard-fail a dax mount if
> > the device doesn't support it, instead of silently disabling the
> > functionality.  Proposing for ext2, ext4, and xfs to keep behavior in
> > sync.
>
> Let me include Dan and Ross into the discussion since they were the ones
> proposing the "silent fallback" behavior (ext4 actually did fail the mount
> instead not so long ago - see 24f3478d664b "ext4: auto disable dax instead
> of failing mount" from December). Guys, why did you choose the fallback
> path instead of a failure?

The different behavior between filesystems was confusing customers so
we had to align them, then the question was which default to pick.
Honestly, we came to the decision to bring ext4 in line with the xfs
behavior because we thought that would be easier than the alternative.
Dave and Christoph made repeated arguments that DAX is just a hidden
performance optimization that no application should rely on, so we
went the path of least resistance and changed the ext4 default.

I'm perfectly fine switching both to the "fail if not DAX device" behavior.