[PATCH] arm64: Add support for hardware updates of the access and dirty pte bits
Will Deacon
will.deacon at arm.com
Thu Sep 10 08:38:12 PDT 2015
On Thu, Sep 10, 2015 at 03:45:25PM +0100, Julien Grall wrote:
> >> Do you have any insight for debugging this problem?
> > [...]
> >>> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> >>> index 39139a3aa16d..a8be513dff6f 100644
> >>> --- a/arch/arm64/mm/proc.S
> >>> +++ b/arch/arm64/mm/proc.S
> >>> @@ -196,6 +196,19 @@ ENTRY(__cpu_setup)
> >>> */
> >>> mrs x9, ID_AA64MMFR0_EL1
> >>> bfi x10, x9, #32, #3
> >>> +#ifdef CONFIG_ARM64_HW_AFDBM
> >>> + /*
> >>> + * Hardware update of the Access and Dirty bits.
> >>> + */
> >>> + mrs x9, ID_AA64MMFR1_EL1
> >>> + and x9, x9, #0xf
> >>> + cbz x9, 2f
> >>> + cmp x9, #2
> >>> + b.lt 1f
> >>> + orr x10, x10, #TCR_HD // hardware Dirty flag update
> >>> +1: orr x10, x10, #TCR_HA // hardware Access flag update
> >>> +2:
> >>> +#endif /* CONFIG_ARM64_HW_AFDBM */
> >>> msr tcr_el1, x10
> >>> ret // return to head.S
> >>> ENDPROC(__cpu_setup)
> >
> > Just in case some ID registers are wrong, can you do an "#if 0" above
> > instead of CONFIG_ARM64_HW_AFDBM?
>
> It doesn't change anything for me. I've also tried the solution
> suggested by Will (see changes below) and I still hit the BUG_ON in the
> fs driver.
>
> The only way to get a usable userspace is disabling CONFIG_ARM64_HW_AFDBM.
Weird. That doesn't leave a lot of code. Two other things you could try
are:
(1) Put PTE_WRITE back to bit 57
(2) Remove the pte_hw_dirty check/set in pte_modify
I thought maybe we could be corrupting a swap entry or something, but I
really can't see how that could happen.
Will
More information about the linux-arm-kernel
mailing list