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  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, 13 Sep 2017 16:48:38 +0200
From:   Jan Kara <>
To:     Ross Zwisler <>
Cc:     Soccer Liu <>,,
        "" <>
Subject: Re: Unexpected writes seen on a Read-only, DAX enabled EXT4 fs

On Mon 11-09-17 12:21:12, Ross Zwisler wrote:
> On Sat, Sep 09, 2017 at 05:10:26PM +0000, Soccer Liu wrote:
> > Hi:
> >   I was surprised to see a few write operations called into
> > ext4_dax_huge_fault with FAULT_FLAG_WRITE set on vmf->flags
> > Are those writes expected at all?
> > static int ext4_dax_huge_fault(struct vm_fault *vmf,
> >  enum page_entry_size pe_size)
> > {
> > ...
> >  bool write = vmf->flags & FAULT_FLAG_WRITE;
> > Based on the following Mount documentation below, I did mount this ext fs
> > with ro and noloadAre there any other options that I could use to totally
> > eliminate those unexpected writes?

Well, I expect these are actually 4KB faults into private mapping (they
would end up using ext4_dax_huge_fault() as well) and the fix Ross
references below should fix that... But please tell if it does not (along
with a reproducer). Thanks!

> Adding the ext4 list.
> I'm pretty sure that this is ext4/mm behavior that is independent of DAX.  DAX
> doesn't really have any impact on whether or not write page faults happen on a
> RO ext4 filesystem, though this fix from Randy Dodgen:
> shows that FAULT_FLAG_WRITE can be set on DAX read-only ext4 mounts when
> executing binaries, though in this case the write is going to a COW page.


Jan Kara <>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ