Re: [PATCH] arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default

From: John Stultz <john.stultz@linaro.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Will Deacon <will@kernel.org>, stable <stable@vger.kernel.org>,
	Alistair Delva <adelva@google.com>,
	Sandeep Patil <sspatil@google.com>
Subject: Re: [PATCH] arm64: Ensure VM_WRITE|VM_SHARED ptes are clean by default
Date: Mon, 4 Nov 2019 17:16:42 -0800	[thread overview]
Message-ID: <CALAqxLXuxZVg0kqNQXF_dH17NzH9m14-Ci_rzruHzmms0V7pvg@mail.gmail.com> (raw)
In-Reply-To: <20191029153051.24367-1-catalin.marinas@arm.com>

On Tue, Oct 29, 2019 at 8:31 AM Catalin Marinas <catalin.marinas@arm.com> 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: <stable@vger.kernel.org> # 4.14.x-
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

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