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: Fri, 16 Mar 2018 12:44:36 +0530	[thread overview]
Message-ID: <7d1716a1-0a69-4851-68c6-ebc00d2e8e1d@codeaurora.org> (raw)
In-Reply-To: <20180315151645.fsgcywyawvtiwx52@lakrids.cambridge.arm.com>



On 3/15/2018 8:46 PM, Mark Rutland wrote:
> On Thu, Mar 15, 2018 at 06:55:32PM +0530, Chintan Pandya wrote:
>> On 3/15/2018 6:43 PM, Mark Rutland wrote:
>>> 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.
> 
> Ok. Just considering the 4K -> 2M case, is that an assumption, or a
> guarantee?
For 4K->2M case, that's confirmed. I mean, while mapping 2M, all the
next level entries will be unmapped and cleared. That gets ensured
before we land to page table code. But if someone calls these page table
APIs directly without respecting previous mappings, we will not hit
BUG_ON() anywhere but a crash later in unfamiliar situations. But that's
the wrong thing to do.

> 
> Thanks,
> Mark.
> 

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-16  7:14 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
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 [this message]
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=7d1716a1-0a69-4851-68c6-ebc00d2e8e1d@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).