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=-5.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 F1EA8C5DF62 for ; Wed, 6 Nov 2019 09:00:02 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 897EF2075C for ; Wed, 6 Nov 2019 09:00:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rZoUS0Jz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 897EF2075C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fw9sJe8kWTyC2VLhqCco6lRdDjwMAxR7YRheoQCI18o=; b=rZoUS0JzheRrHI ngVYwYWjEoRDGlzbieQ/oy1Remh8NDlPBlEwDz6VKXW+1KjcqtvrGmnwbzHK6oeKi65gzSNlIQVfA M9jEudA5Q3xzXKanypbRtHD4B1Ss/+pmZg0K1ro/lLWxzkfnEaVLD/6mZqjv0UAK+JqL9PIxVIU4W 6rvTi9opdfsSWrK1MRG+BXYB8qpMQNq5YDV3ZqZ2novCk9VQjYzKHGm/tkn4+r4lThshP7Hlf4H9v qENUcBG/gUP4pBDTvaR09ZMjbgLkskZ1jYKi+1wAtCjtsx+nK+7B3G9bGGxNIE7mO0Uszq9fs5Phx m6/+/CjQx9oUlVX7/EHQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSHAV-00019j-Ea; Wed, 06 Nov 2019 08:59:59 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iSHAQ-00018I-TL for linux-arm-kernel@lists.infradead.org; Wed, 06 Nov 2019 08:59:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F38B930E; Wed, 6 Nov 2019 00:59:42 -0800 (PST) Received: from arrakis.emea.arm.com (unknown [10.1.197.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EE9493F71A; Wed, 6 Nov 2019 00:59:41 -0800 (PST) Date: Wed, 6 Nov 2019 08:59:39 +0000 From: Catalin Marinas To: John Stultz Subject: Re: [PATCH] arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default Message-ID: <20191106085939.GC21133@arrakis.emea.arm.com> References: <20191029153051.24367-1-catalin.marinas@arm.com> <20191105102902.GB29852@willie-the-truck> <20191105165433.GD22987@arrakis.emea.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191106_005955_932615_9F43EC03 X-CRM114-Status: GOOD ( 21.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alistair Delva , Sandeep Patil , Steve Capper , stable , Will Deacon , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 05, 2019 at 01:17:11PM -0800, John Stultz wrote: > On Tue, Nov 5, 2019 at 8:54 AM Catalin Marinas wrote: > > On Tue, Nov 05, 2019 at 10:29:03AM +0000, Will Deacon wrote: > > > On Mon, Nov 04, 2019 at 05:16:42PM -0800, John Stultz wrote: > > > > On Tue, Oct 29, 2019 at 8:31 AM Catalin Marinas wrote: > > > > > > > > > > Shared and writable mappings (__S.1.) should be clean (!dirty) initially > > > > > and made dirty on a subsequent write either through the hardware DBM > > > > > (dirty bit management) mechanism or through a write page fault. A clean > > > > > pte for the arm64 kernel is one that has PTE_RDONLY set and PTE_DIRTY > > > > > clear. > > > > > > > > > > The PAGE_SHARED{,_EXEC} attributes have PTE_WRITE set (PTE_DBM) and > > > > > PTE_DIRTY clear. Prior to commit 73e86cb03cf2 ("arm64: Move PTE_RDONLY > > > > > bit handling out of set_pte_at()"), it was the responsibility of > > > > > set_pte_at() to set the PTE_RDONLY bit and mark the pte clean if the > > > > > software PTE_DIRTY bit was not set. However, the above commit removed > > > > > the pte_sw_dirty() check and the subsequent setting of PTE_RDONLY in > > > > > set_pte_at() while leaving the PAGE_SHARED{,_EXEC} definitions > > > > > unchanged. The result is that shared+writable mappings are now dirty by > > > > > default > > > > > > > > > > Fix the above by explicitly setting PTE_RDONLY in PAGE_SHARED{,_EXEC}. > > > > > In addition, remove the superfluous PTE_DIRTY bit from the kernel PROT_* > > > > > attributes. > > > > > > > > > > Fixes: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()") > > > > > Cc: # 4.14.x- > > > > > Cc: Will Deacon > > > > > Signed-off-by: Catalin Marinas > > [...] > > > As an experiment, can you try reverting just the part of the patch that > > > removes PTE_DIRTY from the PROT_* definitions? (see below) > > > > Another thing worth trying is reverting commit 747a70e60b72 ("arm64: Fix > > copy-on-write referencing in HugeTLB") when this patch is applied. That > > commit is not just about hugetlb but changes pte_same() to ignore > > PTE_RDONLY on the assumption that this is set by set_pte_at(). We > > subsequently changed set_pte_at() to drop PTE_RDONLY. > > Just to confirm, reverting 747a70e60b72 instead of aa57157be69f also > seems to avoid the issue I'm seeing. Thanks for confirming. I'm not sure about all the interactions in your kernel but just looking at commit 747a70e60b72 it likely needs to be reverted anyway. I'll send a separate patch and hopefully Steve can confirm that it doesn't break the original hugetlb use-case. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel