On Wed, Feb 13, 2019 at 09:37:38AM +0000, Peng Fan wrote:
> The barriers are added for empty_zero_page, however the
> empty zero page has been moved to bss area by
> commit 5227cfa71f9e ("arm64: mm: place empty_zero_page in bss"),
> and it alreay added "dsb ishst" in head.S to make sure
> the empty zero page visible to PTW.
The "zeroed page" the comment refers to is not empty_zero_page.
The page
the comment refers to is an arbitrary page returned by
__get_free_page(), which has been filled with zeroed at some point
thanks to PGALLOC_GFP containing __GFP_ZERO.
> pgd_pgtable_alloc is only called by __create_pgd_mapping, and
> there are implicit barriers in __create_pgd_mapping, so we
> could remove the barrier pgd_pgtable_alloc
I don't think this is true.
Consider:
create_pgd_mapping()
-> __create_pgd_mapping()
-> alloc_init_pud()
-> pgtable_alloc() // pgd_pgtable_alloc()
-> __pgd_populate()
... where AFAICT there is no barrier between pgtable_alloc() and
__pgd_populate().
Where is the barrier between the page zeroing and the update of the pgd
entry?
Thanks,
Mark.
>
> Signed-off-by: Peng Fan <peng....@nxp.com>
> ---
>
> Note: this patch tested on qemu-system-aarch64, not real hardware.
>
> arch/arm64/mm/mmu.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index f61fa7c8fd2e..04e3d4d070ce 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -371,8 +371,6 @@ static phys_addr_t pgd_pgtable_alloc(void)
> if (!ptr || !pgtable_page_ctor(virt_to_page(ptr)))
> BUG();
>
> - /* Ensure the zeroed page is visible to the page table walker */
> - dsb(ishst);
> return __pa(ptr);
> }
>
> --
> 2.16.4
>
