[3/3] arm64: mmu: pgd_pgtable_alloc: drop barrier
diff mbox series

Message ID 20190213094831.7292-3-peng.fan@nxp.com
State New
Headers show
Series
  • [1/3] arm64: mmu: update paging_init comments
Related show

Commit Message

Peng Fan Feb. 13, 2019, 9:37 a.m. UTC
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.

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

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---

Note: this patch tested on qemu-system-aarch64, not real hardware.

 arch/arm64/mm/mmu.c | 2 --
 1 file changed, 2 deletions(-)

Comments

Mark Rutland Feb. 13, 2019, 11:30 a.m. UTC | #1
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.fan@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
>
Peng Fan Feb. 13, 2019, 11:54 a.m. UTC | #2
Hi Mark,

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@arm.com]
> Sent: 2019年2月13日 19:31
> To: Peng Fan <peng.fan@nxp.com>
> Cc: catalin.marinas@arm.com; will.deacon@arm.com;
> ard.biesheuvel@linaro.org; yaojun8558363@gmail.com;
> cpandya@codeaurora.org; robin.murphy@arm.com;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> van.freenix@gmail.com
> Subject: Re: [PATCH 3/3] arm64: mmu: pgd_pgtable_alloc: drop barrier
> 
> 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.

Thanks, I understand wrong.

> 
> 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?

I though the barrier in __pgd_populate could be enough, but this is not
enough, we still need barrier before write pgd/pud/pmd/pte entries.

So drop this patch.

Thanks,
Peng.

> 
> Thanks,
> Mark.
> 
> >
> > Signed-off-by: Peng Fan <peng.fan@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
> >

Patch
diff mbox series

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);
 }