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 6F1CECA9ED3 for ; Tue, 5 Nov 2019 01:16:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 434CE2080F for ; Tue, 5 Nov 2019 01:16:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bCx9UYoy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729796AbfKEBQy (ORCPT ); Mon, 4 Nov 2019 20:16:54 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:38504 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728602AbfKEBQy (ORCPT ); Mon, 4 Nov 2019 20:16:54 -0500 Received: by mail-oi1-f195.google.com with SMTP id v186so16017186oie.5 for ; Mon, 04 Nov 2019 17:16:54 -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=kBeY4f2OvdQA5xTLMkQLC0YdOsAuWNMqH+SmmFAXcgs=; b=bCx9UYoyZMXoeo3o8cc0y22tALdHKfscWqvoj5CIoH+KXchcEQ8N7GY26Iwj1HHWTh 5GSaNGSgUqrYUKv7WUsQ7VZ8NG1PbBsppoGug8I4DEIbcfXGqC0bBkIOpIu08X0E09Oa +Q7gxj/Yt6IeVVLtXM9nayAGqADYROl6IGC0yU3xXkXsMETPoxZu8rO7BNigtGQDc6R3 wJxxMCtvIsRuLF3Vy68ozP0dHrE9SBhxzydlWOwbK3lh/VlIstUu5NM8wA+MD4UVe3cM 8l4JpJApDFg8NUoFqJTvwgdKwbht27ZViljR1/4cz8SPOJYxT8l0J2rQpVm4XlvsUcdl bKaw== 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=kBeY4f2OvdQA5xTLMkQLC0YdOsAuWNMqH+SmmFAXcgs=; b=pf1Ab6a8rB5U2HXrts81SgH85qATgQsp2IUKCAqItJ5suAFHuiAEeBaN87A4HxyCrO AFtq7Ko3BIZTEK9DdgTZ/ymAUKvDzbfpoPYBaL90jlE6TeiUvwRZLoldJI+BhmWg+QyF Lo1x3uUKN5dfkgwStZD047N438pzFc2qidzfYLYU57JqINZMacts2OBw3o+5ZNnBMLql /AUUlWObn+VaREKUIXAogIC8u8/cw9OGFY2N/N/5PjAL0FxUksGs4o9cNb+Osb8G2TmB 5SutpiPQpQ8e+YL8dhjn4yCY7dPI0LGAe8M4F8euHIRo9wkZApuvCL/JyC//rrzcPiwS fOJw== X-Gm-Message-State: APjAAAWFMblNLcxRHjs2cBSpYRfVTfn+Y7HGhzvq/dplxMbi7+KWXiw4 F2e0Bk5xAJek2cyG7pvgjsfxlpmvm3uY5HK8TZztPw== X-Google-Smtp-Source: APXvYqyf7IeMKspg6JW7fJbbf2hW11JVdVyOHNLOnfin4tyCvuxMjfE67fC863wVdT3V1oGIhBhfkC4oLJhg/ULtgGA= X-Received: by 2002:a05:6808:113:: with SMTP id b19mr1571484oie.169.1572916613450; Mon, 04 Nov 2019 17:16:53 -0800 (PST) MIME-Version: 1.0 References: <20191029153051.24367-1-catalin.marinas@arm.com> In-Reply-To: <20191029153051.24367-1-catalin.marinas@arm.com> From: John Stultz Date: Mon, 4 Nov 2019 17:16:42 -0800 Message-ID: Subject: Re: [PATCH] arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default To: Catalin Marinas Cc: linux-arm-kernel , Will Deacon , stable , Alistair Delva , Sandeep Patil 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, 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 Hey, So I'm not yet sure why, but I've just validated that this patch is causing trouble with booting AOSP on HiKey960 with 5.4-rc6 (-rc5 works fine). Its odd, because the system does boot and is alive, but seems to stall out at the boot animation, and userland never finishes coming up to the home screen. It just sits there without a useful error message that I can find so far. Reverting just this patch seems to solve it and it boots all the way. I'll try to dig further to see what might be going on (the mali driver is a prime suspect here), but I wanted to raise the flag since we're at the end of the -rc cycle. 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 B3824CA9ED3 for ; Tue, 5 Nov 2019 01:16:58 +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 893B42080F for ; Tue, 5 Nov 2019 01:16:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="CeDev3DP"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="bCx9UYoy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 893B42080F 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=8iePHkk9woBy89M7n9P99oYZGA7YcG2nJlQeLQAJhPA=; b=CeDev3DP1ORONb pQugQOeBoGNww6QY/EXP9TqdWpvsgGWxPcr0c+P37fYJ2EGMOdMXpbJDEM6j16Grx33fGx2Y4PzgC lUREquLdyN1koruH708junTyrskEdxgKayiOnxXEdMF+P4ZLrKawVADm5GwzjoNYib6pjtv8f2rq7 /qSGuVmvkkczx0xWEkiK0g1Uvu9CSHUDFvw4Hr7ZwtGj9xMvZvVIk3q0zFSWPWdNZaPDQnXgSza8R QlhHO0tBKDyB9e8C61jlN5uSRFY7M60AsIDYdEyDfUyse18MjDJFp2Frgcp5yQj9ZMYFnG4vAeRbh eXDNMaLFzd5pi949vDig==; 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 1iRnSr-0001B1-VR; Tue, 05 Nov 2019 01:16:57 +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 1iRnSp-0001Ab-8D for linux-arm-kernel@lists.infradead.org; Tue, 05 Nov 2019 01:16:56 +0000 Received: by mail-oi1-x243.google.com with SMTP id n14so263871oie.13 for ; Mon, 04 Nov 2019 17:16:54 -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=kBeY4f2OvdQA5xTLMkQLC0YdOsAuWNMqH+SmmFAXcgs=; b=bCx9UYoyZMXoeo3o8cc0y22tALdHKfscWqvoj5CIoH+KXchcEQ8N7GY26Iwj1HHWTh 5GSaNGSgUqrYUKv7WUsQ7VZ8NG1PbBsppoGug8I4DEIbcfXGqC0bBkIOpIu08X0E09Oa +Q7gxj/Yt6IeVVLtXM9nayAGqADYROl6IGC0yU3xXkXsMETPoxZu8rO7BNigtGQDc6R3 wJxxMCtvIsRuLF3Vy68ozP0dHrE9SBhxzydlWOwbK3lh/VlIstUu5NM8wA+MD4UVe3cM 8l4JpJApDFg8NUoFqJTvwgdKwbht27ZViljR1/4cz8SPOJYxT8l0J2rQpVm4XlvsUcdl bKaw== 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=kBeY4f2OvdQA5xTLMkQLC0YdOsAuWNMqH+SmmFAXcgs=; b=PevvLnxQ9anXzZTIyWTMufxp8wSlvy17jp0oEorOoYhAaCUTFH8SfbObbL6gxJQ9aw Fuq/T3i4w0M67LZV6rYeY9YlHXd0fONnOhC+rwKnhDbPnNLnDXNrUL1kGRJoOhOHDmXY 8H6L/1FUuJyZ4QDdQvMZKeD90N5DtDjKcMJ4FbiRXoazyvh+bMMaYUQNZvJgM2I/aF6n baKmiYirRHLySRSKCaz5PfNc2sCEqperjjATO+tn0sTXcQ1idhvVa/yHhakXLQyBdGYj g/uG6McOBBKPIRBWm1+tQxi7+aabIep+O0BHkZFR3uLq1nZrsAKFhIq13ewSP/YWYteR va3A== X-Gm-Message-State: APjAAAW4iue4bUdCUtyRNNQS2sgups3v576LUnfj+LLWOAb0Z0LwrbYO df/zylYV8moyEiTXk0JBrNpmVam3yHOeztFGuhRaSQ== X-Google-Smtp-Source: APXvYqyf7IeMKspg6JW7fJbbf2hW11JVdVyOHNLOnfin4tyCvuxMjfE67fC863wVdT3V1oGIhBhfkC4oLJhg/ULtgGA= X-Received: by 2002:a05:6808:113:: with SMTP id b19mr1571484oie.169.1572916613450; Mon, 04 Nov 2019 17:16:53 -0800 (PST) MIME-Version: 1.0 References: <20191029153051.24367-1-catalin.marinas@arm.com> In-Reply-To: <20191029153051.24367-1-catalin.marinas@arm.com> From: John Stultz Date: Mon, 4 Nov 2019 17:16:42 -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-20191104_171655_299896_CB896AB7 X-CRM114-Status: GOOD ( 18.81 ) 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 , Will Deacon , stable , 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, 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 Hey, So I'm not yet sure why, but I've just validated that this patch is causing trouble with booting AOSP on HiKey960 with 5.4-rc6 (-rc5 works fine). Its odd, because the system does boot and is alive, but seems to stall out at the boot animation, and userland never finishes coming up to the home screen. It just sits there without a useful error message that I can find so far. Reverting just this patch seems to solve it and it boots all the way. I'll try to dig further to see what might be going on (the mali driver is a prime suspect here), but I wanted to raise the flag since we're at the end of the -rc cycle. thanks -john _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel