[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <148804250784.36605.12832323062093584440.stgit@dwillia2-desk3.amr.corp.intel.com>
Date: Sat, 25 Feb 2017 09:08:28 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: akpm@...ux-foundation.org
Cc: x86@...nel.org, Xiong Zhou <xzhou@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
linux-mm@...ck.org, Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
torvalds@...ux-foundation.org,
Ross Zwisler <ross.zwisler@...ux.intel.com>
Subject: [PATCH 0/2] fix for direct-I/O to DAX mappings
Hi Andrew,
While Ross was doing a review of a new mmap+DAX direct-I/O test case for
xfstests, from Xiong, he noticed occasions where it failed to trigger a
page dirty event. Dave then spotted the problem fixed by patch1. The
pte_devmap() check is precluding pte_allows_gup(), i.e. bypassing
permission checks and dirty tracking.
Patch2 is a cleanup and clarifies that pte_unmap() only needs to be done
once per page-worth of ptes. It unifies the exit paths similar to the
generic gup_pte_range() in the __HAVE_ARCH_PTE_SPECIAL case.
I'm sending this through the -mm tree for a double-check from memory
management folks. It has a build success notification from the kbuild
robot.
---
Dan Williams (2):
x86, mm: fix gup_pte_range() vs DAX mappings
x86, mm: unify exit paths in gup_pte_range()
arch/x86/mm/gup.c | 37 +++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
Powered by blists - more mailing lists