On Tue, Nov 5, 2019 at 1:17 PM John Stultz john.stultz@linaro.org wrote:
On Tue, Nov 5, 2019 at 8:54 AM Catalin Marinas catalin.marinas@arm.com 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 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
[...]
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