From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AD7DC43381 for ; Fri, 1 Mar 2019 14:50:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EA9E820675 for ; Fri, 1 Mar 2019 14:50:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387696AbfCAOuC (ORCPT ); Fri, 1 Mar 2019 09:50:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:38158 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728276AbfCAOuC (ORCPT ); Fri, 1 Mar 2019 09:50:02 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3E928B040; Fri, 1 Mar 2019 14:50:00 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 85D061E13E2; Fri, 1 Mar 2019 15:49:59 +0100 (CET) Date: Fri, 1 Mar 2019 15:49:59 +0100 From: Jan Kara To: "Aneesh Kumar K.V" Cc: Jan Kara , Chandan Rajendra , mpe@ellerman.id.au, Dan Williams , linux-fsdevel@vger.kernel.org Subject: Re: write fault on dax mapping and usage of set_pte_at. Message-ID: <20190301144959.GA14863@quack2.suse.cz> References: <871s41a9mo.fsf@linux.ibm.com> <20190221121238.GB21533@quack2.suse.cz> <20190221151513.GB23071@quack2.suse.cz> <87sgwh86rk.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <87sgwh86rk.fsf@linux.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu 21-02-19 21:37:27, Aneesh Kumar K.V wrote: > Jan Kara writes: > > > On Thu 21-02-19 19:11:14, Aneesh Kumar K.V wrote: > >> On 2/21/19 5:42 PM, Jan Kara wrote: > >> > Hi Aneesh, > >> > > >> > On Thu 21-02-19 12:52:39, Aneesh Kumar K.V wrote: > > > >> Do pfn_mkwrite callback need to insert the pfn details for a RO->RW fault > >> type? Can't we skip that pfn insert and let finish_mkwrite_fault handle that > >> pte update? > > > > Yes, pfn_mkwrite() must fully update the PTE as the PTE update must happen > > under a lock that is private to DAX code. Using ptep_set_access_flags() > > in iomap code isn't going to be simple either. I have to think whether / > > how that is possible. > > Can we use ptep_clear_flush followed by set_pte_at()? So in the end the thing was simpler than I thought. Does attached patch fix the warnings for you? Honza -- Jan Kara SUSE Labs, CR --qDbXVdCdHGoSgWSk Content-Type: text/x-patch; charset=us-ascii Content-Disposition: attachment; filename="0001-mm-Fix-modifying-of-page-protection-by-insert_pfn.patch" >From ab5d1bbd74bc67982203b79a3748e3784a71b589 Mon Sep 17 00:00:00 2001 From: Jan Kara Date: Fri, 1 Mar 2019 15:16:11 +0100 Subject: [PATCH] mm: Fix modifying of page protection by insert_pfn() Aneesh has reported that PPC triggers the following warning when excercising DAX code: [c00000000007610c] set_pte_at+0x3c/0x190 LR [c000000000378628] insert_pfn+0x208/0x280 Call Trace: [c0000002125df980] [8000000000000104] 0x8000000000000104 (unreliable) [c0000002125df9c0] [c000000000378488] insert_pfn+0x68/0x280 [c0000002125dfa30] [c0000000004a5494] dax_iomap_pte_fault.isra.7+0x734/0xa40 [c0000002125dfb50] [c000000000627250] __xfs_filemap_fault+0x280/0x2d0 [c0000002125dfbb0] [c000000000373abc] do_wp_page+0x48c/0xa40 [c0000002125dfc00] [c000000000379170] __handle_mm_fault+0x8d0/0x1fd0 [c0000002125dfd00] [c00000000037a9b0] handle_mm_fault+0x140/0x250 [c0000002125dfd40] [c000000000074bb0] __do_page_fault+0x300/0xd60 [c0000002125dfe20] [c00000000000acf4] handle_page_fault+0x18 Now that is WARN_ON in set_pte_at which is VM_WARN_ON(pte_hw_valid(*ptep) && !pte_protnone(*ptep)); The problem is that on some architectures set_pte_at() cannot cope with a situation where there is already some (different) valid entry present. Use ptep_set_access_flags() instead to modify the pfn which is built to deal with modifying existing PTE. Reported-by: "Aneesh Kumar K.V" Signed-off-by: Jan Kara --- mm/memory.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index e11ca9dd823f..ebca3071278a 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1546,10 +1546,12 @@ static vm_fault_t insert_pfn(struct vm_area_struct *vma, unsigned long addr, WARN_ON_ONCE(!is_zero_pfn(pte_pfn(*pte))); goto out_unlock; } - entry = *pte; - goto out_mkwrite; - } else - goto out_unlock; + entry = pte_mkyoung(*pte); + entry = maybe_mkwrite(pte_mkdirty(entry), vma); + if (ptep_set_access_flags(vma, addr, pte, entry, 1)) + update_mmu_cache(vma, addr, pte); + } + goto out_unlock; } /* Ok, finally just insert the thing.. */ @@ -1558,7 +1560,6 @@ static vm_fault_t insert_pfn(struct vm_area_struct *vma, unsigned long addr, else entry = pte_mkspecial(pfn_t_pte(pfn, prot)); -out_mkwrite: if (mkwrite) { entry = pte_mkyoung(entry); entry = maybe_mkwrite(pte_mkdirty(entry), vma); -- 2.16.4 --qDbXVdCdHGoSgWSk--