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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 9909AC5DF60 for ; Tue, 5 Nov 2019 21:30:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 567DB21929 for ; Tue, 5 Nov 2019 21:30:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="yxFFwBbF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729698AbfKEVaC (ORCPT ); Tue, 5 Nov 2019 16:30:02 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:40866 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730163AbfKEVaB (ORCPT ); Tue, 5 Nov 2019 16:30:01 -0500 Received: by mail-oi1-f193.google.com with SMTP id 22so859947oip.7 for ; Tue, 05 Nov 2019 13:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MKex/i2q2cLUhnrOZHb/aTfSgxLlxLOB7hwQ/W42MOw=; b=yxFFwBbFJuRUmrLRu10ZGRWzKFrK7/48YyA7Ncx1ZigYrzwB8XSeGTQmsue6WKWmSJ Xfe0oir5wnBLctIZp9L+juUiBycM6ZTvBtI+BNK4TtUaT7fcE75tSlsPnxEHp9UKahbz 2hpMQA0b1ljhgjAucbg/dmSp2YGsqIQSvrhr5/r/p+eVAgFppBggggHoTEoj4hUxiryz Od37e8JexbJXGc9eI2TCXsU0X2LxLGic4ZFevFWgFwqpifNeSD15vXG1GGJlLQtgZXav t5TZWpVaSxnlO3F7KDScwucNanRdQ8eZ9FhGnEM+wUILlxc9m8A2ymCJzDbA8wLDhXr5 2URw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MKex/i2q2cLUhnrOZHb/aTfSgxLlxLOB7hwQ/W42MOw=; b=DfI6tpHZnY2ffxl4sXjEgDT1bDO8gOAuNpudw9de+6TL4adBlrrXGj4Ew8g9CYGZQI VtH6o3HBxyY+oGN2zr2bLz4akh5hls9mkZoBuv2yiAwZuBkjQHy2qRl7mupoeVJRHASJ +CJjnuaIeACjcgFXBDj+5yRHrXSGOS6z4Cfx9yqWg/SHCEyvdJQp0BLrlgcl8YHz5i0/ hbSHEsdj47xAkcajH5T5yFikmBy1qQ05o/9ADI5XAL/l0sLHgAr4vhqU6BA231GcJqZR Q8ahE8Y3XOHShJykj/ZMlvWHBO4kES370wAnffyzK+KuUeo3DtbtjLLiAM7cUpSX8X2O W6gQ== X-Gm-Message-State: APjAAAWinffY9kiQf2YbA9B7WNFaaLVZrwDIcVD5k73wRFZcw22nbLKq Bt5sBODbWLpTOo9dbDbL/OMgEPV87J+u5sckoqiD2w== X-Google-Smtp-Source: APXvYqyzj5HURLTlobaqoi8hTKrbUECVIYX+Szr2iuPljx86BKtHnCHUZsYoXa9CppTgl3WUix0tHrwd6NrPPAarr4s= X-Received: by 2002:aca:3a41:: with SMTP id h62mr990522oia.97.1572989400562; Tue, 05 Nov 2019 13:30:00 -0800 (PST) MIME-Version: 1.0 References: <20191029153051.24367-1-catalin.marinas@arm.com> <20191105102902.GB29852@willie-the-truck> <20191105165433.GD22987@arrakis.emea.arm.com> In-Reply-To: From: John Stultz Date: Tue, 5 Nov 2019 13:29:49 -0800 Message-ID: Subject: Re: [PATCH] arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default To: Catalin Marinas Cc: Will Deacon , Alistair Delva , Sandeep Patil , stable , linux-arm-kernel , Steve Capper Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Tue, Nov 5, 2019 at 1:17 PM 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. > > I've not tried Will patch but I'll do that next. Though its not clear > if you wanted me to revert 747a70e60b72 on top of Will's test patch or > not? Not sure if its useful data, but while Will's patch on its own didn't change the behavior, it along with reverting 747a70e60b72 seems to work the same as just reverting 747a70e60b72 alone. thanks -john 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=-3.8 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 autolearn=no 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 50D73C5DF60 for ; Tue, 5 Nov 2019 21:30:15 +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 04FA121A4A for ; Tue, 5 Nov 2019 21:30:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="T/PB+X/9"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="yxFFwBbF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04FA121A4A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2FeR36RHpzVcvArWa9OZgCHTuzBQ18oiQqSESkkpqik=; b=T/PB+X/9sdLkYM xirLjlt3V49v/leD1HOPUpna0ha131yteOYCS+VyG0gIm71reM7FgVTJUQvXCcKCIQlnB0MV5A6fp IJvgOJIfrGlITsXlezHG736U7qV4BPBQtNYol4rzQIY0Xt5VPdKT21mJEtDqDdWHFq9yT9byQ2vIu 64kZEsk313sSxE1YjD1CjCEjMbdzZJDHkw6OZhg23OgvrI60AjmwAyCWH9s0ODYJ4S8xVGsBqerjQ PLIUNHh4IV1/fLfho/iJMwlkbmwCJGPTrgUV/I4gBfhs/1dX4LZOkxae+JBKVkUUli55qRGcVAnk3 UsWYvadEy/GCvXAZCYOw==; 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 1iS6Or-000236-F5; Tue, 05 Nov 2019 21:30:05 +0000 Received: from mail-oi1-x243.google.com ([2607:f8b0:4864:20::243]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iS6Oo-0001Xm-3g for linux-arm-kernel@lists.infradead.org; Tue, 05 Nov 2019 21:30:03 +0000 Received: by mail-oi1-x243.google.com with SMTP id l20so6894125oie.10 for ; Tue, 05 Nov 2019 13:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MKex/i2q2cLUhnrOZHb/aTfSgxLlxLOB7hwQ/W42MOw=; b=yxFFwBbFJuRUmrLRu10ZGRWzKFrK7/48YyA7Ncx1ZigYrzwB8XSeGTQmsue6WKWmSJ Xfe0oir5wnBLctIZp9L+juUiBycM6ZTvBtI+BNK4TtUaT7fcE75tSlsPnxEHp9UKahbz 2hpMQA0b1ljhgjAucbg/dmSp2YGsqIQSvrhr5/r/p+eVAgFppBggggHoTEoj4hUxiryz Od37e8JexbJXGc9eI2TCXsU0X2LxLGic4ZFevFWgFwqpifNeSD15vXG1GGJlLQtgZXav t5TZWpVaSxnlO3F7KDScwucNanRdQ8eZ9FhGnEM+wUILlxc9m8A2ymCJzDbA8wLDhXr5 2URw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MKex/i2q2cLUhnrOZHb/aTfSgxLlxLOB7hwQ/W42MOw=; b=m9r7qqOgemgKpYUJ7NxKCtFEscuhqLWT6lyPhX+lmOQyq2MwKjW7k/d22O2YcRk97p gNO+FkEEF9X976YVpMnn58lDC1z1zQEYnIHH5bxT6o2yPN2LUXSj6PLNoSag6YczKpkb PhlwIm4H1+iEFaxrha6Z6e4BRUnNr9qwjBmjujDoA5K0sUkTjEgWXMNsSAoe7yLadkPO X3XiLnMjWaltpbfC4OvE7kNTdlc43qjZb8Zh8VnCMos27zA4LtRHy4irPP4xVDiM+Dyy zZFpPeOHv/i9gpUYtyRTRVLiMOHxeQllKMN4CQLIORFafnllD7BDIT+Ncz0oSsdwkWPG 4c7g== X-Gm-Message-State: APjAAAVN54S5dBQf89CibXiWdV2/Fv86QcQALv9f7U94BONdUZl8yGHZ ksKG+ReWYPXEY6tOPzSLR06vReMCLhfeBs71X0HWvg== X-Google-Smtp-Source: APXvYqyzj5HURLTlobaqoi8hTKrbUECVIYX+Szr2iuPljx86BKtHnCHUZsYoXa9CppTgl3WUix0tHrwd6NrPPAarr4s= X-Received: by 2002:aca:3a41:: with SMTP id h62mr990522oia.97.1572989400562; Tue, 05 Nov 2019 13:30:00 -0800 (PST) MIME-Version: 1.0 References: <20191029153051.24367-1-catalin.marinas@arm.com> <20191105102902.GB29852@willie-the-truck> <20191105165433.GD22987@arrakis.emea.arm.com> In-Reply-To: From: John Stultz Date: Tue, 5 Nov 2019 13:29:49 -0800 Message-ID: Subject: Re: [PATCH] arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default To: Catalin Marinas X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191105_133002_168242_ECFA0A37 X-CRM114-Status: GOOD ( 22.15 ) 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 5, 2019 at 1:17 PM 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. > > I've not tried Will patch but I'll do that next. Though its not clear > if you wanted me to revert 747a70e60b72 on top of Will's test patch or > not? Not sure if its useful data, but while Will's patch on its own didn't change the behavior, it along with reverting 747a70e60b72 seems to work the same as just reverting 747a70e60b72 alone. thanks -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel