[PATCH V3 0/2] mm/ioremap: Check virtual address alignment

[PATCH V3 0/2] mm/ioremap: Check virtual address alignment

[Anshuman Khandual]

This series makes sure that ioremap_page_range()'s input virtual address
alignment is checked along with physical address before creating huge page
kernel mappings to avoid problems related to random freeing of PMD or PTE
pgtable pages potentially with existing valid entries. It also cleans up
arm64 pgtable page address offset in [pud|pmd]_free_[pmd|pte]_page().

Changes in V3:

- Added virtual address alignment check in ioremap_page_range()
- Dropped VM_WARN_ONCE() as input virtual addresses are aligned for sure

Changes in V2: (https://patchwork.kernel.org/patch/10922795/)

- Replaced WARN_ON_ONCE() with VM_WARN_ONCE() as per Catalin

Changes in V1: (https://patchwork.kernel.org/patch/10921135/)

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Chintan Pandya <cpandya@codeaurora.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Laura Abbott <labbott@redhat.com>

Anshuman Khandual (2):
  mm/ioremap: Check virtual address alignment while creating huge mappings
  arm64/mm: Change offset base address in [pud|pmd]_free_[pmd|pte]_page()

 arch/arm64/mm/mmu.c | 6 +++---
 lib/ioremap.c       | 6 ++++++
 2 files changed, 9 insertions(+), 3 deletions(-)

-- 
2.20.1

[PATCH V3 1/2] mm/ioremap: Check virtual address alignment while creating huge mappings

[Anshuman Khandual]

Virtual address alignment is essential in ensuring correct clearing for all
intermediate level pgtable entries and freeing associated pgtable pages. An
unaligned address can end up randomly freeing pgtable page that potentially
still contains valid mappings. Hence also check it's alignment along with
existing phys_addr check.

Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Chintan Pandya <cpandya@codeaurora.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
 lib/ioremap.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lib/ioremap.c b/lib/ioremap.c
index 063213685563..8b5c8dda857d 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -86,6 +86,9 @@ static int ioremap_try_huge_pmd(pmd_t *pmd, unsigned long addr,
 	if ((end - addr) != PMD_SIZE)
 		return 0;
 
+	if (!IS_ALIGNED(addr, PMD_SIZE))
+		return 0;
+
 	if (!IS_ALIGNED(phys_addr, PMD_SIZE))
 		return 0;
 
@@ -126,6 +129,9 @@ static int ioremap_try_huge_pud(pud_t *pud, unsigned long addr,
 	if ((end - addr) != PUD_SIZE)
 		return 0;
 
+	if (!IS_ALIGNED(addr, PUD_SIZE))
+		return 0;
+
 	if (!IS_ALIGNED(phys_addr, PUD_SIZE))
 		return 0;
 
-- 
2.20.1

Re: [PATCH V3 1/2] mm/ioremap: Check virtual address alignment while creating huge mappings

[Kani, Toshi]

On Thu, 2019-05-09 at 10:16 +0530, Anshuman Khandual wrote:
> Virtual address alignment is essential in ensuring correct clearing for all
> intermediate level pgtable entries and freeing associated pgtable pages. An
> unaligned address can end up randomly freeing pgtable page that potentially
> still contains valid mappings. Hence also check it's alignment along with
> existing phys_addr check.
> 
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Toshi Kani <toshi.kani@hpe.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Chintan Pandya <cpandya@codeaurora.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  lib/ioremap.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/lib/ioremap.c b/lib/ioremap.c
> index 063213685563..8b5c8dda857d 100644
> --- a/lib/ioremap.c
> +++ b/lib/ioremap.c
> @@ -86,6 +86,9 @@ static int ioremap_try_huge_pmd(pmd_t *pmd, unsigned long addr,
>  	if ((end - addr) != PMD_SIZE)
>  		return 0;
>  
> +	if (!IS_ALIGNED(addr, PMD_SIZE))
> +		return 0;
> +
>  	if (!IS_ALIGNED(phys_addr, PMD_SIZE))
>  		return 0;
>  
> @@ -126,6 +129,9 @@ static int ioremap_try_huge_pud(pud_t *pud, unsigned long addr,
>  	if ((end - addr) != PUD_SIZE)
>  		return 0;
>  
> +	if (!IS_ALIGNED(addr, PUD_SIZE))
> +		return 0;
> +
>  	if (!IS_ALIGNED(phys_addr, PUD_SIZE))
>  		return 0;

Not sure if we have such case today, but I agree that it is prudent to
have such checks.  Is there any reason not to add this check to p4d for
consistency?

Thanks,
-Toshi

Re: [PATCH V3 1/2] mm/ioremap: Check virtual address alignment while creating huge mappings

[Anshuman Khandual]

On 05/14/2019 03:56 AM, Kani, Toshi wrote:
> On Thu, 2019-05-09 at 10:16 +0530, Anshuman Khandual wrote:
>> Virtual address alignment is essential in ensuring correct clearing for all
>> intermediate level pgtable entries and freeing associated pgtable pages. An
>> unaligned address can end up randomly freeing pgtable page that potentially
>> still contains valid mappings. Hence also check it's alignment along with
>> existing phys_addr check.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> Cc: Toshi Kani <toshi.kani@hpe.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Chintan Pandya <cpandya@codeaurora.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>>  lib/ioremap.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/lib/ioremap.c b/lib/ioremap.c
>> index 063213685563..8b5c8dda857d 100644
>> --- a/lib/ioremap.c
>> +++ b/lib/ioremap.c
>> @@ -86,6 +86,9 @@ static int ioremap_try_huge_pmd(pmd_t *pmd, unsigned long addr,
>>  	if ((end - addr) != PMD_SIZE)
>>  		return 0;
>>  
>> +	if (!IS_ALIGNED(addr, PMD_SIZE))
>> +		return 0;
>> +
>>  	if (!IS_ALIGNED(phys_addr, PMD_SIZE))
>>  		return 0;
>>  
>> @@ -126,6 +129,9 @@ static int ioremap_try_huge_pud(pud_t *pud, unsigned long addr,
>>  	if ((end - addr) != PUD_SIZE)
>>  		return 0;
>>  
>> +	if (!IS_ALIGNED(addr, PUD_SIZE))
>> +		return 0;
>> +
>>  	if (!IS_ALIGNED(phys_addr, PUD_SIZE))
>>  		return 0;
> 
> Not sure if we have such case today, but I agree that it is prudent to
> have such checks.  Is there any reason not to add this check to p4d for
> consistency?

No, will add it.

[PATCH V4] mm/ioremap: Check virtual address alignment while creating huge mappings

[Anshuman Khandual]

Virtual address alignment is essential in ensuring correct clearing for all
intermediate level pgtable entries and freeing associated pgtable pages. An
unaligned address can end up randomly freeing pgtable page that potentially
still contains valid mappings. Hence also check it's alignment along with
existing phys_addr check.

Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Toshi Kani <toshi.kani@hpe.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Chintan Pandya <cpandya@codeaurora.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
Changes in V4:

- Added similar check for ioremap_try_huge_p4d() as per Toshi Kani

 lib/ioremap.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/lib/ioremap.c b/lib/ioremap.c
index 063213685563..a95161d9c883 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -86,6 +86,9 @@ static int ioremap_try_huge_pmd(pmd_t *pmd, unsigned long addr,
 	if ((end - addr) != PMD_SIZE)
 		return 0;
 
+	if (!IS_ALIGNED(addr, PMD_SIZE))
+		return 0;
+
 	if (!IS_ALIGNED(phys_addr, PMD_SIZE))
 		return 0;
 
@@ -126,6 +129,9 @@ static int ioremap_try_huge_pud(pud_t *pud, unsigned long addr,
 	if ((end - addr) != PUD_SIZE)
 		return 0;
 
+	if (!IS_ALIGNED(addr, PUD_SIZE))
+		return 0;
+
 	if (!IS_ALIGNED(phys_addr, PUD_SIZE))
 		return 0;
 
@@ -166,6 +172,9 @@ static int ioremap_try_huge_p4d(p4d_t *p4d, unsigned long addr,
 	if ((end - addr) != P4D_SIZE)
 		return 0;
 
+	if (!IS_ALIGNED(addr, P4D_SIZE))
+		return 0;
+
 	if (!IS_ALIGNED(phys_addr, P4D_SIZE))
 		return 0;
 
-- 
2.20.1

Re: [PATCH V4] mm/ioremap: Check virtual address alignment while creating huge mappings

[Will Deacon]

On Wed, May 15, 2019 at 08:05:16AM +0530, Anshuman Khandual wrote:
> Virtual address alignment is essential in ensuring correct clearing for all
> intermediate level pgtable entries and freeing associated pgtable pages. An
> unaligned address can end up randomly freeing pgtable page that potentially
> still contains valid mappings. Hence also check it's alignment along with
> existing phys_addr check.
> 
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Toshi Kani <toshi.kani@hpe.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Chintan Pandya <cpandya@codeaurora.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> Changes in V4:
> 
> - Added similar check for ioremap_try_huge_p4d() as per Toshi Kani

Sorry to be a pain, but in future please can you just resend the entire
series as a v4 (after giving it a few days for any other comments to come
in) if you make an update? It's a bit fiddly tracking which replies to which
individual patches need to be picked up, although I'm sure this varies
between maintainers.

No need to do anything this time, but just a small ask for future patches.

Will

Re: [PATCH V4] mm/ioremap: Check virtual address alignment while creating huge mappings

[Anshuman Khandual]

On 05/15/2019 03:16 PM, Will Deacon wrote:
> On Wed, May 15, 2019 at 08:05:16AM +0530, Anshuman Khandual wrote:
>> Virtual address alignment is essential in ensuring correct clearing for all
>> intermediate level pgtable entries and freeing associated pgtable pages. An
>> unaligned address can end up randomly freeing pgtable page that potentially
>> still contains valid mappings. Hence also check it's alignment along with
>> existing phys_addr check.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> Cc: Toshi Kani <toshi.kani@hpe.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Chintan Pandya <cpandya@codeaurora.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>> Changes in V4:
>>
>> - Added similar check for ioremap_try_huge_p4d() as per Toshi Kani
> 
> Sorry to be a pain, but in future please can you just resend the entire
> series as a v4 (after giving it a few days for any other comments to come
> in) if you make an update? It's a bit fiddly tracking which replies to which
> individual patches need to be picked up, although I'm sure this varies
> between maintainers.

I wondered for some time about both the ways before landing on this side as it was
pretty minor change. I understand the concern and will follow the suggestion next
time around. If this one requires further update, will make it V5 and carry the
change logs from here.

> 
> No need to do anything this time, but just a small ask for future patches.

Sure will do.

Re: [PATCH V4] mm/ioremap: Check virtual address alignment while creating huge mappings

[Kani, Toshi]

On Wed, 2019-05-15 at 08:05 +0530, Anshuman Khandual wrote:
> Virtual address alignment is essential in ensuring correct clearing for all
> intermediate level pgtable entries and freeing associated pgtable pages. An
> unaligned address can end up randomly freeing pgtable page that potentially
> still contains valid mappings. Hence also check it's alignment along with
> existing phys_addr check.
> 
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Toshi Kani <toshi.kani@hpe.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Chintan Pandya <cpandya@codeaurora.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> ---
> Changes in V4:
> 
> - Added similar check for ioremap_try_huge_p4d() as per Toshi Kani

Thanks for the update. It looks good to me.

Reviewed-by: Toshi Kani <toshi.kani@hpe.com>

-Toshi

Re: [PATCH V4] mm/ioremap: Check virtual address alignment while creating huge mappings

[Catalin Marinas]

On Wed, May 15, 2019 at 08:05:16AM +0530, Anshuman Khandual wrote:
> Virtual address alignment is essential in ensuring correct clearing for all
> intermediate level pgtable entries and freeing associated pgtable pages. An
> unaligned address can end up randomly freeing pgtable page that potentially
> still contains valid mappings. Hence also check it's alignment along with
> existing phys_addr check.
> 
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Toshi Kani <toshi.kani@hpe.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Chintan Pandya <cpandya@codeaurora.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Catalin Marinas <catalin.marinas@arm.com>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

I guess Andrew can pick this up, otherwise I can queue it through arm64
(there are no arm64 dependencies on this).

Thanks.

-- 
Catalin

[PATCH V3 2/2] arm64/mm: Change offset base address in [pud|pmd]_free_[pmd|pte]_page()

[Anshuman Khandual]

Pgtable page address can be fetched with [pmd|pte]_offset_[kernel] if input
address is PMD_SIZE or PTE_SIZE aligned. Input address is now guaranteed to
be aligned, hence fetched pgtable page address is always correct. But using
0UL as offset base address has been a standard practice across platforms.
It also makes more sense as it isolates pgtable page address computation
from input virtual address alignment. This does not change functionality.

Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
---
 arch/arm64/mm/mmu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e97f018ff740..71bcb783aace 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1005,7 +1005,7 @@ int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
 		return 1;
 	}
 
-	table = pte_offset_kernel(pmdp, addr);
+	table = pte_offset_kernel(pmdp, 0UL);
 	pmd_clear(pmdp);
 	__flush_tlb_kernel_pgtable(addr);
 	pte_free_kernel(NULL, table);
@@ -1026,8 +1026,8 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
 		return 1;
 	}
 
-	table = pmd_offset(pudp, addr);
-	pmdp = table;
+	table = pmd_offset(pudp, 0UL);
+	pmdp = pmd_offset(pudp, addr);
 	next = addr;
 	end = addr + PUD_SIZE;
 	do {
-- 
2.20.1

Re: [PATCH V3 2/2] arm64/mm: Change offset base address in [pud|pmd]_free_[pmd|pte]_page()

[Catalin Marinas]

Hi Anshuman,


On Thu, May 09, 2019 at 10:16:17AM +0530, Anshuman Khandual wrote:
> Pgtable page address can be fetched with [pmd|pte]_offset_[kernel] if input
> address is PMD_SIZE or PTE_SIZE aligned. Input address is now guaranteed to
> be aligned, hence fetched pgtable page address is always correct. But using
> 0UL as offset base address has been a standard practice across platforms.
> It also makes more sense as it isolates pgtable page address computation
> from input virtual address alignment. This does not change functionality.
> 
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>

What's the plan with this small series? I didn't find a v5 (unless I
deleted it by mistake). I can queue this patch through the arm64 tree or
they can both go in via the mm tree.

-- 
Catalin

Re: [PATCH V3 2/2] arm64/mm: Change offset base address in [pud|pmd]_free_[pmd|pte]_page()

[Anshuman Khandual]

On 06/03/2019 09:06 PM, Catalin Marinas wrote:
> Hi Anshuman,
> 
> 
> On Thu, May 09, 2019 at 10:16:17AM +0530, Anshuman Khandual wrote:
>> Pgtable page address can be fetched with [pmd|pte]_offset_[kernel] if input
>> address is PMD_SIZE or PTE_SIZE aligned. Input address is now guaranteed to
>> be aligned, hence fetched pgtable page address is always correct. But using
>> 0UL as offset base address has been a standard practice across platforms.
>> It also makes more sense as it isolates pgtable page address computation
>> from input virtual address alignment. This does not change functionality.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: James Morse <james.morse@arm.com>
>> Cc: Robin Murphy <robin.murphy@arm.com>
> 
> What's the plan with this small series? I didn't find a v5 (unless I
> deleted it by mistake). I can queue this patch through the arm64 tree or
> they can both go in via the mm tree.

As mentioned earlier [1] I believe the second patch is not needed anymore. Hence
only V4 of the first patch (https://patchwork.kernel.org/patch/10944191/) which
has a Reviewed-by tag should be considered.

[1] https://patchwork.kernel.org/patch/10936625/

Re: [PATCH V3 2/2] arm64/mm: Change offset base address in [pud|pmd]_free_[pmd|pte]_page()

[Catalin Marinas]

On Thu, May 09, 2019 at 10:16:17AM +0530, Anshuman Khandual wrote:
> Pgtable page address can be fetched with [pmd|pte]_offset_[kernel] if input
> address is PMD_SIZE or PTE_SIZE aligned. Input address is now guaranteed to
> be aligned, hence fetched pgtable page address is always correct. But using
> 0UL as offset base address has been a standard practice across platforms.
> It also makes more sense as it isolates pgtable page address computation
> from input virtual address alignment. This does not change functionality.
> 
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> ---
>  arch/arm64/mm/mmu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index e97f018ff740..71bcb783aace 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1005,7 +1005,7 @@ int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
>  		return 1;
>  	}
>  
> -	table = pte_offset_kernel(pmdp, addr);
> +	table = pte_offset_kernel(pmdp, 0UL);
>  	pmd_clear(pmdp);
>  	__flush_tlb_kernel_pgtable(addr);
>  	pte_free_kernel(NULL, table);
> @@ -1026,8 +1026,8 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
>  		return 1;
>  	}
>  
> -	table = pmd_offset(pudp, addr);
> -	pmdp = table;
> +	table = pmd_offset(pudp, 0UL);
> +	pmdp = pmd_offset(pudp, addr);
>  	next = addr;
>  	end = addr + PUD_SIZE;
>  	do {

I have the same comment as last time:

https://lore.kernel.org/linux-arm-kernel/20190430161759.GI29799@arrakis.emea.arm.com/

I don't see why pmdp needs to be different from table. We get the
pointer to a pmd page and we want to iterate over it to free the pte
entries it contains. You can add a VM_WARN on addr alignment as in the
previous version of the patch but pmdp is just an iterator over table.

-- 
Catalin

Re: [PATCH V3 2/2] arm64/mm: Change offset base address in [pud|pmd]_free_[pmd|pte]_page()

[Anshuman Khandual]

On 06/04/2019 07:54 PM, Catalin Marinas wrote:
> On Thu, May 09, 2019 at 10:16:17AM +0530, Anshuman Khandual wrote:
>> Pgtable page address can be fetched with [pmd|pte]_offset_[kernel] if input
>> address is PMD_SIZE or PTE_SIZE aligned. Input address is now guaranteed to
>> be aligned, hence fetched pgtable page address is always correct. But using
>> 0UL as offset base address has been a standard practice across platforms.
>> It also makes more sense as it isolates pgtable page address computation
>> from input virtual address alignment. This does not change functionality.
>>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: James Morse <james.morse@arm.com>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> ---
>>  arch/arm64/mm/mmu.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index e97f018ff740..71bcb783aace 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1005,7 +1005,7 @@ int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
>>  		return 1;
>>  	}
>>  
>> -	table = pte_offset_kernel(pmdp, addr);
>> +	table = pte_offset_kernel(pmdp, 0UL);
>>  	pmd_clear(pmdp);
>>  	__flush_tlb_kernel_pgtable(addr);
>>  	pte_free_kernel(NULL, table);
>> @@ -1026,8 +1026,8 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
>>  		return 1;
>>  	}
>>  
>> -	table = pmd_offset(pudp, addr);
>> -	pmdp = table;
>> +	table = pmd_offset(pudp, 0UL);
>> +	pmdp = pmd_offset(pudp, addr);
>>  	next = addr;
>>  	end = addr + PUD_SIZE;
>>  	do {
> 
> I have the same comment as last time:
> 
> https://lore.kernel.org/linux-arm-kernel/20190430161759.GI29799@arrakis.emea.arm.com/
> 
> I don't see why pmdp needs to be different from table. We get the
> pointer to a pmd page and we want to iterate over it to free the pte
> entries it contains. You can add a VM_WARN on addr alignment as in the
> previous version of the patch but pmdp is just an iterator over table.

Fair enough. I believe VM_WARN() is needed to check address alignment because
they are now guaranteed to be aligned because of the previous patch. I guess
we should probably drop this patch and consider only the previous one ?