From patchwork Thu Nov 19 00:36:24 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Zwisler X-Patchwork-Id: 7653731 Return-Path: X-Original-To: patchwork-linux-nvdimm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id C0EA69F1C2 for ; Thu, 19 Nov 2015 00:36:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D8C4920456 for ; Thu, 19 Nov 2015 00:36:34 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0AD4820452 for ; Thu, 19 Nov 2015 00:36:34 +0000 (UTC) Received: from ml01.vlan14.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id E92DA1A20AD; Wed, 18 Nov 2015 16:36:33 -0800 (PST) X-Original-To: linux-nvdimm@ml01.01.org Delivered-To: linux-nvdimm@ml01.01.org Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ml01.01.org (Postfix) with ESMTP id BEE6C1A20AD for ; Wed, 18 Nov 2015 16:36:32 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 18 Nov 2015 16:36:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,315,1444719600"; d="scan'208";a="854133134" Received: from theros.lm.intel.com (HELO linux.intel.com) ([10.232.112.87]) by orsmga002.jf.intel.com with ESMTP; 18 Nov 2015 16:36:24 -0800 Date: Wed, 18 Nov 2015 17:36:24 -0700 From: Ross Zwisler To: Toshi Kani Subject: Re: dax pmd fault handler never returns to userspace Message-ID: <20151119003624.GA26287@linux.intel.com> Mail-Followup-To: Ross Zwisler , Toshi Kani , Dan Williams , linux-nvdimm , Ross Zwisler , linux-fsdevel , linux-ext4 References: <20151118170014.GB10656@linux.intel.com> <20151118182320.GA7901@linux.intel.com> <1447882389.21443.151.camel@hpe.com> <1447884281.21443.154.camel@hpe.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1447884281.21443.154.camel@hpe.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: linux-nvdimm , Ross Zwisler , linux-fsdevel , linux-ext4 X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Nov 18, 2015 at 03:04:41PM -0700, Toshi Kani wrote: > On Wed, 2015-11-18 at 13:57 -0800, Dan Williams wrote: > > On Wed, Nov 18, 2015 at 1:33 PM, Toshi Kani wrote: > > > I am seeing a similar/same problem in my test. I think the problem is that > > > in > > > case of a WP fault, wp_huge_pmd() -> __dax_pmd_fault() -> > > > vmf_insert_pfn_pmd(), > > > which is a no-op since the PMD is mapped already. We need WP handling for > > > this > > > PMD map. > > > > > > If it helps, I have attached change for follow_trans_huge_pmd(). I have not > > > tested much, though. > > > > Interesting, I didn't get this far because my tests were crashing the > > kernel. I'll add this case the pmd fault test in ndctl. > > I hit this one with mmap(MAP_POPULATE). With this change, I then hit the WP > fault loop when writing to the range. Here's a fix - please let me know if this seems incomplete or incorrect for some reason. -- >8 -- From 02aa9f37d7ec9c0c38413f7e304b2577eb9f974a Mon Sep 17 00:00:00 2001 From: Ross Zwisler Date: Wed, 18 Nov 2015 17:15:09 -0700 Subject: [PATCH] mm: Allow DAX PMD mappings to become writeable Prior to this change DAX PMD mappings that were made read-only were never able to be made writable again. This is because the code in insert_pfn_pmd() that calls pmd_mkdirty() and pmd_mkwrite() would skip these calls if the PMD already existed in the page table. Instead, if we are doing a write always mark the PMD entry as dirty and writeable. Without this code we can get into a condition where we mark the PMD as read-only, and then on a subsequent write fault we get into an infinite loop of PMD faults where we try unsuccessfully to make the PMD writeable. Signed-off-by: Ross Zwisler --- mm/huge_memory.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index bbac913..1b3df56 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -877,15 +877,13 @@ static void insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr, spinlock_t *ptl; ptl = pmd_lock(mm, pmd); - if (pmd_none(*pmd)) { - entry = pmd_mkhuge(pfn_pmd(pfn, prot)); - if (write) { - entry = pmd_mkyoung(pmd_mkdirty(entry)); - entry = maybe_pmd_mkwrite(entry, vma); - } - set_pmd_at(mm, addr, pmd, entry); - update_mmu_cache_pmd(vma, addr, pmd); + entry = pmd_mkhuge(pfn_pmd(pfn, prot)); + if (write) { + entry = pmd_mkyoung(pmd_mkdirty(entry)); + entry = maybe_pmd_mkwrite(entry, vma); } + set_pmd_at(mm, addr, pmd, entry); + update_mmu_cache_pmd(vma, addr, pmd); spin_unlock(ptl); }