linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chintan Pandya <cpandya@codeaurora.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: catalin.marinas@arm.com, will.deacon@arm.com, arnd@arndb.de,
	ard.biesheuvel@linaro.org, marc.zyngier@arm.com,
	james.morse@arm.com, kristina.martsenko@arm.com,
	takahiro.akashi@linaro.org, gregkh@linuxfoundation.org,
	tglx@linutronix.de, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	akpm@linux-foundation.org, toshi.kani@hpe.com
Subject: Re: [PATCH v2 2/4] ioremap: Implement TLB_INV before huge mapping
Date: Thu, 15 Mar 2018 18:55:32 +0530	[thread overview]
Message-ID: <839387ee-e1c2-cc71-c06a-7bc2d0eda73d@codeaurora.org> (raw)
In-Reply-To: <20180315131316.fd5ftqwgdb5bf5we@lakrids.cambridge.arm.com>



On 3/15/2018 6:43 PM, Mark Rutland wrote:
> Hi,
> 
> As a general note, pleas wrap commit text to 72 characters.
> 
> On Thu, Mar 15, 2018 at 06:15:04PM +0530, Chintan Pandya wrote:
>> Huge mapping changes PMD/PUD which could have
>> valid previous entries. This requires proper
>> TLB maintanance on some architectures, like
>> ARM64.
> 
> Just to check, I take it that you mean we could have a valid table
> entry, but all the entries in that next level table must be invalid,
> right?

That was my assumption but my assumption can be wrong if any VA gets
block mapping for 1G directly (instead of the 2M cases we discussed
so far), then this would go for a toss.

> 
>>
>> Implent BBM (break-before-make) safe TLB
>> invalidation.
>>
>> Here, I've used flush_tlb_pgtable() instead
>> of flush_kernel_range() because invalidating
>> intermediate page_table entries could have
>> been optimized for specific arch. That's the
>> case with ARM64 at least.
> 
> ... because if there are valid entries in the next level table,
> __flush_tlb_pgtable() is not sufficient to ensure all of these are
> removed from the TLB.

oh !! In case of huge_pgd, next level pmd may or may not be valid. So, 
better I be using flush_kernel_range()

I will upload v3. But, would wait for other comments...

> 
> Assuming that all entries in the next level table are invalid, this
> looks ok to me.
> 
> Thanks,
> Mark.
> 
>> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
>> ---
>>   lib/ioremap.c | 25 +++++++++++++++++++------
>>   1 file changed, 19 insertions(+), 6 deletions(-)
>>
>> diff --git a/lib/ioremap.c b/lib/ioremap.c
>> index 54e5bba..55f8648 100644
>> --- a/lib/ioremap.c
>> +++ b/lib/ioremap.c
>> @@ -13,6 +13,7 @@
>>   #include <linux/export.h>
>>   #include <asm/cacheflush.h>
>>   #include <asm/pgtable.h>
>> +#include <asm-generic/tlb.h>
>>   
>>   #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>>   static int __read_mostly ioremap_p4d_capable;
>> @@ -80,6 +81,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr,
>>   		unsigned long end, phys_addr_t phys_addr, pgprot_t prot)
>>   {
>>   	pmd_t *pmd;
>> +	pmd_t old_pmd;
>>   	unsigned long next;
>>   
>>   	phys_addr -= addr;
>> @@ -91,10 +93,15 @@ 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)) {
>> -			if (pmd_set_huge(pmd, phys_addr + addr, prot))
>> +		    IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
>> +			old_pmd = *pmd;
>> +			pmd_clear(pmd);
>> +			flush_tlb_pgtable(&init_mm, addr);
>> +			if (pmd_set_huge(pmd, phys_addr + addr, prot)) {
>> +				pmd_free_pte_page(&old_pmd);
>>   				continue;
>> +			} else
>> +				set_pmd(pmd, old_pmd);
>>   		}
>>   
>>   		if (ioremap_pte_range(pmd, addr, next, phys_addr + addr, prot))
>> @@ -107,6 +114,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr,
>>   		unsigned long end, phys_addr_t phys_addr, pgprot_t prot)
>>   {
>>   	pud_t *pud;
>> +	pud_t old_pud;
>>   	unsigned long next;
>>   
>>   	phys_addr -= addr;
>> @@ -118,10 +126,15 @@ 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)) {
>> -			if (pud_set_huge(pud, phys_addr + addr, prot))
>> +		    IS_ALIGNED(phys_addr + addr, PUD_SIZE)) {
>> +			old_pud = *pud;
>> +			pud_clear(pud);
>> +			flush_tlb_pgtable(&init_mm, addr);
>> +			if (pud_set_huge(pud, phys_addr + addr, prot)) {
>> +				pud_free_pmd_page(&old_pud);
>>   				continue;
>> +			} else
>> +				set_pud(pud, old_pud);
>>   		}
>>   
>>   		if (ioremap_pmd_range(pud, addr, next, phys_addr + addr, prot))
>> -- 
>> Qualcomm India Private Limited, on behalf of Qualcomm Innovation
>> Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
>> Collaborative Project
>>

Chintan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project

  parent reply	other threads:[~2018-03-15 13:25 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 12:45 [PATCH v2 0/4] Fix issues with huge mapping in ioremap for ARM64 Chintan Pandya
2018-03-15 12:45 ` Chintan Pandya
2018-03-15 12:45 ` [PATCH v2 1/4] asm/tlbflush: Add flush_tlb_pgtable() " Chintan Pandya
2018-03-15 12:45   ` Chintan Pandya
2018-03-15 12:45 ` [PATCH v2 2/4] ioremap: Implement TLB_INV before huge mapping Chintan Pandya
2018-03-15 12:45   ` Chintan Pandya
2018-03-15 13:13   ` Mark Rutland
2018-03-15 13:13     ` Mark Rutland
2018-03-15 13:25     ` Chintan Pandya [this message]
2018-03-15 13:25       ` Chintan Pandya
2018-03-15 15:16       ` Mark Rutland
2018-03-15 15:16         ` Mark Rutland
2018-03-16  7:14         ` Chintan Pandya
2018-03-16  7:14           ` Chintan Pandya
2018-03-15 13:31   ` Mark Rutland
2018-03-15 13:31     ` Mark Rutland
2018-03-15 14:19     ` Chintan Pandya
2018-03-15 14:19       ` Chintan Pandya
2018-03-15 15:20       ` Mark Rutland
2018-03-15 15:20         ` Mark Rutland
2018-03-15 16:12   ` Kani, Toshi
2018-03-15 16:12     ` Kani, Toshi
2018-03-16  7:40     ` Chintan Pandya
2018-03-16  7:40       ` Chintan Pandya
2018-03-16 14:50       ` Kani, Toshi
2018-03-16 14:50         ` Kani, Toshi
2018-03-19  4:26         ` Chintan Pandya
2018-03-19  4:26           ` Chintan Pandya
2018-03-15 12:45 ` [PATCH v2 3/4] arm64: Implement page table free interfaces Chintan Pandya
2018-03-15 12:45   ` Chintan Pandya
2018-03-15 13:18   ` Mark Rutland
2018-03-15 13:18     ` Mark Rutland
2018-03-19  4:29     ` Chintan Pandya
2018-03-19  4:29       ` Chintan Pandya
2018-03-15 12:45 ` [PATCH v2 4/4] Revert "arm64: Enforce BBM for huge IO/VMAP mappings" Chintan Pandya
2018-03-15 12:45   ` Chintan Pandya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=839387ee-e1c2-cc71-c06a-7bc2d0eda73d@codeaurora.org \
    --to=cpandya@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.morse@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=tglx@linutronix.de \
    --cc=toshi.kani@hpe.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).