diff mbox

[v4,2/3] ioremap: Update pgtable free interfaces with addr

Message ID 20180627141348.21777-3-toshi.kani@hpe.com (mailing list archive)
State New, archived
Headers show

Commit Message

Kani, Toshi June 27, 2018, 2:13 p.m. UTC 
From: Chintan Pandya <cpandya@codeaurora.org>

The following kernel panic was observed on ARM64 platform due to a stale
TLB entry.

 1. ioremap with 4K size, a valid pte page table is set.
 2. iounmap it, its pte entry is set to 0.
 3. ioremap the same address with 2M size, update its pmd entry with
    a new value.
 4. CPU may hit an exception because the old pmd entry is still in TLB,
    which leads to a kernel panic.

Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
table") has addressed this panic by falling to pte mappings in the above
case on ARM64.

To support pmd mappings in all cases, TLB purge needs to be performed
in this case on ARM64.

Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
so that TLB purge can be added later in seprate patches.

[toshi.kani@hpe.com: merge changes, rewrite patch description]
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: <stable@vger.kernel.org>
---
 arch/arm64/mm/mmu.c           |    4 ++--
 arch/x86/mm/pgtable.c         |   12 +++++++-----
 include/asm-generic/pgtable.h |    8 ++++----
 lib/ioremap.c                 |    4 ++--
 4 files changed, 15 insertions(+), 13 deletions(-)

Comments

Will Deacon June 27, 2018, 3:56 p.m. UTC | #1 
Hi Toshi,

On Wed, Jun 27, 2018 at 08:13:47AM -0600, Toshi Kani wrote:
> From: Chintan Pandya <cpandya@codeaurora.org>
> 
> The following kernel panic was observed on ARM64 platform due to a stale
> TLB entry.
> 
>  1. ioremap with 4K size, a valid pte page table is set.
>  2. iounmap it, its pte entry is set to 0.
>  3. ioremap the same address with 2M size, update its pmd entry with
>     a new value.
>  4. CPU may hit an exception because the old pmd entry is still in TLB,
>     which leads to a kernel panic.
> 
> Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> table") has addressed this panic by falling to pte mappings in the above
> case on ARM64.
> 
> To support pmd mappings in all cases, TLB purge needs to be performed
> in this case on ARM64.
> 
> Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
> so that TLB purge can be added later in seprate patches.

So I acked v13 of Chintan's series posted here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582953.html

any chance this lot could all be merged together, please?

Will
Kani, Toshi June 27, 2018, 4:13 p.m. UTC | #2 
On Wed, 2018-06-27 at 16:56 +0100, Will Deacon wrote:
> Hi Toshi,
> 
> On Wed, Jun 27, 2018 at 08:13:47AM -0600, Toshi Kani wrote:
> > From: Chintan Pandya <cpandya@codeaurora.org>
> > 
> > The following kernel panic was observed on ARM64 platform due to a stale
> > TLB entry.
> > 
> >  1. ioremap with 4K size, a valid pte page table is set.
> >  2. iounmap it, its pte entry is set to 0.
> >  3. ioremap the same address with 2M size, update its pmd entry with
> >     a new value.
> >  4. CPU may hit an exception because the old pmd entry is still in TLB,
> >     which leads to a kernel panic.
> > 
> > Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> > table") has addressed this panic by falling to pte mappings in the above
> > case on ARM64.
> > 
> > To support pmd mappings in all cases, TLB purge needs to be performed
> > in this case on ARM64.
> > 
> > Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
> > so that TLB purge can be added later in seprate patches.
> 
> So I acked v13 of Chintan's series posted here:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582953.html
> 
> any chance this lot could all be merged together, please?

Hi Will,

Chintan's patch 2/3 and 3/3 apply cleanly on top of my series. Can you
please coordinate with Thomas on the logistics?

Thanks,
-Toshi
Will Deacon June 29, 2018, 12:23 p.m. UTC | #3 
Hi Toshi, Thomas,

On Wed, Jun 27, 2018 at 04:13:22PM +0000, Kani, Toshi wrote:
> On Wed, 2018-06-27 at 16:56 +0100, Will Deacon wrote:
> > On Wed, Jun 27, 2018 at 08:13:47AM -0600, Toshi Kani wrote:
> > > From: Chintan Pandya <cpandya@codeaurora.org>
> > > 
> > > The following kernel panic was observed on ARM64 platform due to a stale
> > > TLB entry.
> > > 
> > >  1. ioremap with 4K size, a valid pte page table is set.
> > >  2. iounmap it, its pte entry is set to 0.
> > >  3. ioremap the same address with 2M size, update its pmd entry with
> > >     a new value.
> > >  4. CPU may hit an exception because the old pmd entry is still in TLB,
> > >     which leads to a kernel panic.
> > > 
> > > Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> > > table") has addressed this panic by falling to pte mappings in the above
> > > case on ARM64.
> > > 
> > > To support pmd mappings in all cases, TLB purge needs to be performed
> > > in this case on ARM64.
> > > 
> > > Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
> > > so that TLB purge can be added later in seprate patches.
> > 
> > So I acked v13 of Chintan's series posted here:
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582953.html
> > 
> > any chance this lot could all be merged together, please?
> 
> Chintan's patch 2/3 and 3/3 apply cleanly on top of my series. Can you
> please coordinate with Thomas on the logistics?

Sure. I guess having this series on a common branch that I can pull into
arm64 and apply Chintan's other patches on top would work.

How does that sound?

Will
Kani, Toshi June 29, 2018, 4:01 p.m. UTC | #4 
On Fri, 2018-06-29 at 13:23 +0100, Will Deacon wrote:
> Hi Toshi, Thomas,
> 
> On Wed, Jun 27, 2018 at 04:13:22PM +0000, Kani, Toshi wrote:
> > On Wed, 2018-06-27 at 16:56 +0100, Will Deacon wrote:
> > > On Wed, Jun 27, 2018 at 08:13:47AM -0600, Toshi Kani wrote:
> > > > From: Chintan Pandya <cpandya@codeaurora.org>
> > > > 
> > > > The following kernel panic was observed on ARM64 platform due to a stale
> > > > TLB entry.
> > > > 
> > > >  1. ioremap with 4K size, a valid pte page table is set.
> > > >  2. iounmap it, its pte entry is set to 0.
> > > >  3. ioremap the same address with 2M size, update its pmd entry with
> > > >     a new value.
> > > >  4. CPU may hit an exception because the old pmd entry is still in TLB,
> > > >     which leads to a kernel panic.
> > > > 
> > > > Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> > > > table") has addressed this panic by falling to pte mappings in the above
> > > > case on ARM64.
> > > > 
> > > > To support pmd mappings in all cases, TLB purge needs to be performed
> > > > in this case on ARM64.
> > > > 
> > > > Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
> > > > so that TLB purge can be added later in seprate patches.
> > > 
> > > So I acked v13 of Chintan's series posted here:
> > > 
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582953.html
> > > 
> > > any chance this lot could all be merged together, please?
> > 
> > Chintan's patch 2/3 and 3/3 apply cleanly on top of my series. Can you
> > please coordinate with Thomas on the logistics?
> 
> Sure. I guess having this series on a common branch that I can pull into
> arm64 and apply Chintan's other patches on top would work.
> 
> How does that sound?

Should this go thru -mm tree then?

Andrew, Thomas, what do you think? 

Thanks,
-Toshi
Thomas Gleixner July 3, 2018, 9:02 p.m. UTC | #5 
On Fri, 29 Jun 2018, Kani, Toshi wrote:
> On Fri, 2018-06-29 at 13:23 +0100, Will Deacon wrote:
> > Hi Toshi, Thomas,
> > 
> > On Wed, Jun 27, 2018 at 04:13:22PM +0000, Kani, Toshi wrote:
> > > On Wed, 2018-06-27 at 16:56 +0100, Will Deacon wrote:
> > > > On Wed, Jun 27, 2018 at 08:13:47AM -0600, Toshi Kani wrote:
> > > > > From: Chintan Pandya <cpandya@codeaurora.org>
> > > > > 
> > > > > The following kernel panic was observed on ARM64 platform due to a stale
> > > > > TLB entry.
> > > > > 
> > > > >  1. ioremap with 4K size, a valid pte page table is set.
> > > > >  2. iounmap it, its pte entry is set to 0.
> > > > >  3. ioremap the same address with 2M size, update its pmd entry with
> > > > >     a new value.
> > > > >  4. CPU may hit an exception because the old pmd entry is still in TLB,
> > > > >     which leads to a kernel panic.
> > > > > 
> > > > > Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> > > > > table") has addressed this panic by falling to pte mappings in the above
> > > > > case on ARM64.
> > > > > 
> > > > > To support pmd mappings in all cases, TLB purge needs to be performed
> > > > > in this case on ARM64.
> > > > > 
> > > > > Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
> > > > > so that TLB purge can be added later in seprate patches.
> > > > 
> > > > So I acked v13 of Chintan's series posted here:
> > > > 
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582953.html
> > > > 
> > > > any chance this lot could all be merged together, please?
> > > 
> > > Chintan's patch 2/3 and 3/3 apply cleanly on top of my series. Can you
> > > please coordinate with Thomas on the logistics?
> > 
> > Sure. I guess having this series on a common branch that I can pull into
> > arm64 and apply Chintan's other patches on top would work.
> > 
> > How does that sound?
> 
> Should this go thru -mm tree then?
> 
> Andrew, Thomas, what do you think? 

I just pick it up and provide Will a branch to pull that lot from.

Thanks,

	tglx
Will Deacon July 4, 2018, 5:36 p.m. UTC | #6 
On Tue, Jul 03, 2018 at 11:02:15PM +0200, Thomas Gleixner wrote:
> On Fri, 29 Jun 2018, Kani, Toshi wrote:
> > On Fri, 2018-06-29 at 13:23 +0100, Will Deacon wrote:
> > > On Wed, Jun 27, 2018 at 04:13:22PM +0000, Kani, Toshi wrote:
> > > > On Wed, 2018-06-27 at 16:56 +0100, Will Deacon wrote:
> > > > > On Wed, Jun 27, 2018 at 08:13:47AM -0600, Toshi Kani wrote:
> > > > > > From: Chintan Pandya <cpandya@codeaurora.org>
> > > > > > 
> > > > > > The following kernel panic was observed on ARM64 platform due to a stale
> > > > > > TLB entry.
> > > > > > 
> > > > > >  1. ioremap with 4K size, a valid pte page table is set.
> > > > > >  2. iounmap it, its pte entry is set to 0.
> > > > > >  3. ioremap the same address with 2M size, update its pmd entry with
> > > > > >     a new value.
> > > > > >  4. CPU may hit an exception because the old pmd entry is still in TLB,
> > > > > >     which leads to a kernel panic.
> > > > > > 
> > > > > > Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> > > > > > table") has addressed this panic by falling to pte mappings in the above
> > > > > > case on ARM64.
> > > > > > 
> > > > > > To support pmd mappings in all cases, TLB purge needs to be performed
> > > > > > in this case on ARM64.
> > > > > > 
> > > > > > Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
> > > > > > so that TLB purge can be added later in seprate patches.
> > > > > 
> > > > > So I acked v13 of Chintan's series posted here:
> > > > > 
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582953.html
> > > > > 
> > > > > any chance this lot could all be merged together, please?
> > > > 
> > > > Chintan's patch 2/3 and 3/3 apply cleanly on top of my series. Can you
> > > > please coordinate with Thomas on the logistics?
> > > 
> > > Sure. I guess having this series on a common branch that I can pull into
> > > arm64 and apply Chintan's other patches on top would work.
> > > 
> > > How does that sound?
> > 
> > Should this go thru -mm tree then?
> > 
> > Andrew, Thomas, what do you think? 
> 
> I just pick it up and provide Will a branch to pull that lot from.

Thanks, Thomas. Please let me know once you've pushed something out.

Will
Thomas Gleixner July 4, 2018, 7:39 p.m. UTC | #7 
On Wed, 4 Jul 2018, Will Deacon wrote:
> On Tue, Jul 03, 2018 at 11:02:15PM +0200, Thomas Gleixner wrote:
> 
> > I just pick it up and provide Will a branch to pull that lot from.
> 
> Thanks, Thomas. Please let me know once you've pushed something out.

Just pushed it out into tip x86/mm branch. It's based on -rc3 and you can
consume it up to

  5e0fb5df2ee8 ("x86/mm: Add TLB purge to free pmd/pte page interfaces")

Please wait until tomorrow morning so the 0day robot can chew on it. If
nothing breaks, then it should be good to pull from.

Thanks,

	tglx
Will Deacon July 5, 2018, 5:16 p.m. UTC | #8 
On Wed, Jul 04, 2018 at 09:39:50PM +0200, Thomas Gleixner wrote:
> On Wed, 4 Jul 2018, Will Deacon wrote:
> > On Tue, Jul 03, 2018 at 11:02:15PM +0200, Thomas Gleixner wrote:
> > 
> > > I just pick it up and provide Will a branch to pull that lot from.
> > 
> > Thanks, Thomas. Please let me know once you've pushed something out.
> 
> Just pushed it out into tip x86/mm branch. It's based on -rc3 and you can
> consume it up to
> 
>   5e0fb5df2ee8 ("x86/mm: Add TLB purge to free pmd/pte page interfaces")
> 
> Please wait until tomorrow morning so the 0day robot can chew on it. If
> nothing breaks, then it should be good to pull from.

Great, thanks Thomas. It looks like the bot's happy with that, so I've
pulled it locally and I'll push it out as part of the arm64 for-next/core
branch tomorrow, after some basic tests.

Will
diff mbox

Patch

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 493ff75670ff..8ae5d7ae4af3 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -977,12 +977,12 @@  int pmd_clear_huge(pmd_t *pmdp)
 	return 1;
 }
 
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
 {
 	return pud_none(*pud);
 }
 
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
 {
 	return pmd_none(*pmd);
 }
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 1aeb7a5dbce5..fbd14e506758 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -723,11 +723,12 @@  int pmd_clear_huge(pmd_t *pmd)
 /**
  * pud_free_pmd_page - Clear pud entry and free pmd page.
  * @pud: Pointer to a PUD.
+ * @addr: Virtual address associated with pud.
  *
  * Context: The pud range has been unmaped and TLB purged.
  * Return: 1 if clearing the entry succeeded. 0 otherwise.
  */
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
 {
 	pmd_t *pmd;
 	int i;
@@ -738,7 +739,7 @@  int pud_free_pmd_page(pud_t *pud)
 	pmd = (pmd_t *)pud_page_vaddr(*pud);
 
 	for (i = 0; i < PTRS_PER_PMD; i++)
-		if (!pmd_free_pte_page(&pmd[i]))
+		if (!pmd_free_pte_page(&pmd[i], addr + (i * PMD_SIZE)))
 			return 0;
 
 	pud_clear(pud);
@@ -750,11 +751,12 @@  int pud_free_pmd_page(pud_t *pud)
 /**
  * pmd_free_pte_page - Clear pmd entry and free pte page.
  * @pmd: Pointer to a PMD.
+ * @addr: Virtual address associated with pmd.
  *
  * Context: The pmd range has been unmaped and TLB purged.
  * Return: 1 if clearing the entry succeeded. 0 otherwise.
  */
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
 {
 	pte_t *pte;
 
@@ -770,7 +772,7 @@  int pmd_free_pte_page(pmd_t *pmd)
 
 #else /* !CONFIG_X86_64 */
 
-int pud_free_pmd_page(pud_t *pud)
+int pud_free_pmd_page(pud_t *pud, unsigned long addr)
 {
 	return pud_none(*pud);
 }
@@ -779,7 +781,7 @@  int pud_free_pmd_page(pud_t *pud)
  * Disable free page handling on x86-PAE. This assures that ioremap()
  * does not update sync'd pmd entries. See vmalloc_sync_one().
  */
-int pmd_free_pte_page(pmd_t *pmd)
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
 {
 	return pmd_none(*pmd);
 }
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index f59639afaa39..b081794ba135 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1019,8 +1019,8 @@  int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot);
 int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
 int pud_clear_huge(pud_t *pud);
 int pmd_clear_huge(pmd_t *pmd);
-int pud_free_pmd_page(pud_t *pud);
-int pmd_free_pte_page(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud, unsigned long addr);
+int pmd_free_pte_page(pmd_t *pmd, unsigned long addr);
 #else	/* !CONFIG_HAVE_ARCH_HUGE_VMAP */
 static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot)
 {
@@ -1046,11 +1046,11 @@  static inline int pmd_clear_huge(pmd_t *pmd)
 {
 	return 0;
 }
-static inline int pud_free_pmd_page(pud_t *pud)
+static inline int pud_free_pmd_page(pud_t *pud, unsigned long addr)
 {
 	return 0;
 }
-static inline int pmd_free_pte_page(pmd_t *pmd)
+static inline int pmd_free_pte_page(pmd_t *pmd, unsigned long addr)
 {
 	return 0;
 }
diff --git a/lib/ioremap.c b/lib/ioremap.c
index 54e5bbaa3200..517f5853ffed 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -92,7 +92,7 @@  static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr,
 		if (ioremap_pmd_enabled() &&
 		    ((next - addr) == PMD_SIZE) &&
 		    IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
-		    pmd_free_pte_page(pmd)) {
+		    pmd_free_pte_page(pmd, addr)) {
 			if (pmd_set_huge(pmd, phys_addr + addr, prot))
 				continue;
 		}
@@ -119,7 +119,7 @@  static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr,
 		if (ioremap_pud_enabled() &&
 		    ((next - addr) == PUD_SIZE) &&
 		    IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
-		    pud_free_pmd_page(pud)) {
+		    pud_free_pmd_page(pud, addr)) {
 			if (pud_set_huge(pud, phys_addr + addr, prot))
 				continue;
 		}