linux-kernel - Re: [PATCH v2 0/4] Write protect DAX PMDs in *sync path

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]

Message-ID: <20170106181819.GA3486@linux.intel.com>
Date:   Fri, 6 Jan 2017 11:18:19 -0700
From:   Ross Zwisler <ross.zwisler@...ux.intel.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Ross Zwisler <ross.zwisler@...ux.intel.com>,
        linux-kernel@...r.kernel.org,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Arnd Bergmann <arnd@...db.de>, Christoph Hellwig <hch@....de>,
        Dan Williams <dan.j.williams@...el.com>,
        Dave Chinner <david@...morbit.com>,
        Dave Hansen <dave.hansen@...el.com>, Jan Kara <jack@...e.cz>,
        Matthew Wilcox <mawilcox@...rosoft.com>,
        linux-arch@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, linux-nvdimm@...1.01.org
Subject: Re: [PATCH v2 0/4] Write protect DAX PMDs in *sync path

On Thu, Jan 05, 2017 at 05:27:34PM -0800, Andrew Morton wrote:
> On Tue, 3 Jan 2017 17:13:49 -0700 Ross Zwisler <ross.zwisler@...ux.intel.com> wrote:
> 
> > On Thu, Dec 22, 2016 at 02:18:52PM -0700, Ross Zwisler wrote:
> > > Currently dax_mapping_entry_mkclean() fails to clean and write protect the
> > > pmd_t of a DAX PMD entry during an *sync operation.  This can result in
> > > data loss, as detailed in patch 4.
> > > 
> > > You can find a working tree here:
> > > 
> > > https://git.kernel.org/cgit/linux/kernel/git/zwisler/linux.git/log/?h=dax_pmd_clean_v2
> > > 
> > > This series applies cleanly to mmotm-2016-12-19-16-31.
> > > 
> > > Changes since v1:
> > >  - Included Dan's patch to kill DAX support for UML.
> > >  - Instead of wrapping the DAX PMD code in dax_mapping_entry_mkclean() in
> > >    an #ifdef, we now create a stub for pmdp_huge_clear_flush() for the case
> > >    when CONFIG_TRANSPARENT_HUGEPAGE isn't defined. (Dan & Jan)
> > > 
> > > Dan Williams (1):
> > >   dax: kill uml support
> > > 
> > > Ross Zwisler (3):
> > >   dax: add stub for pmdp_huge_clear_flush()
> > >   mm: add follow_pte_pmd()
> > >   dax: wrprotect pmd_t in dax_mapping_entry_mkclean
> > > 
> > >  fs/Kconfig                    |  2 +-
> > >  fs/dax.c                      | 49 ++++++++++++++++++++++++++++++-------------
> > >  include/asm-generic/pgtable.h | 10 +++++++++
> > >  include/linux/mm.h            |  4 ++--
> > >  mm/memory.c                   | 41 ++++++++++++++++++++++++++++--------
> > >  5 files changed, 79 insertions(+), 27 deletions(-)
> > 
> > Well, 0-day found another architecture that doesn't define pmd_pfn() et al.,
> > so we'll need some more fixes. (Thank you, 0-day, for the coverage!)
> > 
> > I have to apologize, I didn't understand that Dan intended his "dax: kill uml
> > support" patch to land in v4.11.  I thought he intended it as a cleanup to my
> > series, which really needs to land in v4.10.  That's why I folded them
> > together into this v2, along with the wrapper suggested by Jan.
> > 
> > Andrew, does it work for you to just keep v1 of this series, and eventually
> > send that to Linus for v4.10?
> > 
> > https://lkml.org/lkml/2016/12/20/649
> > 
> > You've already pulled that one into -mm, and it does correctly solve the data
> > loss issue.
> > 
> > That would let us deal with getting rid of the #ifdef, blacklisting
> > architectures and introducing the pmdp_huge_clear_flush() strub in a follow-on
> > series for v4.11.
> 
> I have mm-add-follow_pte_pmd.patch and
> dax-wrprotect-pmd_t-in-dax_mapping_entry_mkclean.patch queued for 4.10.
> Please (re)send any additional patches, indicating for each one
> whether you believe it should also go into 4.10?

The two patches that you already have queued are correct, and no additional
patches are necessary for v4.10 for this issue.