Message-ID: <23fc2527-cd32-4750-9b3b-df65f4f76609@arm.com>
Date: Fri, 30 May 2025 11:51:38 +0100
From: Ryan Roberts <ryan.roberts@....com>
To: Dev Jain <dev.jain@....com>, akpm@...ux-foundation.org, david@...hat.com,
 catalin.marinas@....com, will@...nel.org
Cc: lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
 rppt@...nel.org, surenb@...gle.com, mhocko@...e.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, suzuki.poulose@....com, steven.price@....com,
 gshan@...hat.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/3] Enable huge-vmalloc permission change

On 30/05/2025 11:42, Dev Jain wrote:
> 
> On 30/05/25 4:07 pm, Ryan Roberts wrote:
>> On 30/05/2025 11:10, Dev Jain wrote:
>>> On 30/05/25 3:33 pm, Ryan Roberts wrote:
>>>> On 30/05/2025 10:04, Dev Jain wrote:
>>>>> This series paves the path to enable huge mappings in vmalloc space by
>>>>> default on arm64. > For this we must ensure that we can handle any permission
>>>>> games on vmalloc space.
>>>> And the linear map :)
>>>>
>>>>> Currently, __change_memory_common() uses
>>>>> apply_to_page_range() which does not support changing permissions for
>>>>> leaf mappings.
>>>> nit: A "leaf mapping" is the lowest level entry in the page tables for a given
>>>> address - i.e. it maps an address to some actual memory rather than to another
>>>> pgtable. It includes what the Arm ARM calls "page mappings" (PTE level) and
>>>> "block mappings" (PMD/PUD/.. level). apply_to_page_range() does support page
>>>> mappings, so saying it doesn't support leaf mappings is incorrect. It doesn't
>>>> support block mappings.
>>> Sorry, again got confused by nomenclature : )
>>>
>>>>> We attempt to move away from this by using walk_page_range_novma(),
>>>>> similar to what riscv does right now; however, it is the responsibility
>>>>> of the caller to ensure that we do not pass a range, or split the range
>>>>> covering a partial leaf mapping.
>>>>>
>>>>> This series is tied with Yang Shi's attempt [1] at using huge mappings
>>>>> in the linear mapping in case the system supports BBML2, in which case
>>>>> we will be able to split the linear mapping if needed without break-before-
>>>>> make.
>>>>> Thus, Yang's series, IIUC, will be one such user of my series; suppose we
>>>>> are changing permissions on a range of the linear map backed by PMD-hugepages,
>>>>> then the sequence of operations should look like the following:
>>>>>
>>>>> split_range(start, (start + HPAGE_PMD_SIZE) & ~HPAGE_PMD_MASK);
>>>>> split_range(end & ~HPAGE_PMD_MASK, end);
>>>> I don't understand what the HPAGE_PMD_MASK twiddling is doing? That's not
>>>> right.
>>>> It's going to give you the offset within the 2M region. You just want:
>>>>
>>>> split_range(start)
>>>> split_range(end)
>>>>
>>>> right?
>>> Suppose start = 2M + 4K, end = 8M + 5K. Then my sequence will compute to
>> 8M + 5K is not a valid split point. It has to be at least page aligned.
> 
> Sorry, so consider 8M + 4K.
> 
>>> split_range(2M + 4K, 3M)
>>> split_range(8M, 8M + 5K)
>> We just want to split at start and end. What are the 3M and 8M params supposed
>> to be? Anyway, this is off-topic for this series.
> 
> I think we are both saying the same thing; yes we will split only the start and
> the end,
> so if the address 2Mb + 4Kb is mapped as a PMD-hugepage, we need to split this
> PMD into
> a PTE table, which will map 2Mb till 4Mb as base pages now.

Not quite; if you start with [2M, 4M) mapped by PMD, then want to ensure a
boundary at 2M+4K, I think you would end up with the first 64K (16 pages) mapped
by base page, then the then the next 1984K mapped by contpte blocks (31 contpte
blocks).

But yes, we agree :)

> 
>>
>>> __change_memory_common(2M + 4K, 8M + 5K)
>>>
>>> So now __change_memory_common() wouldn't have to deal with splitting the
>>> starts and ends. Please correct me if I am wrong.
>>>
>>>>> __change_memory_common(start, end);
>>>>>
>>>>> However, this series can be used independently of Yang's; since currently
>>>>> permission games are being played only on pte mappings (due to
>>>>> apply_to_page_range
>>>>> not supporting otherwise), this series provides the mechanism for enabling
>>>>> huge mappings for various kernel mappings like linear map and vmalloc.
>>>> In other words, you are saying that this series is a prerequisite for Yang's
>>>> series (and both are prerequisites for huge vmalloc by default). Your series
>>>> adds a new capability that Yang's series will rely on (the ability to change
>>>> permissions on block mappings).
>>> That's right.
>>>
>>>> Thanks,
>>>> Ryan
>>>>
>>>>> [1] https://lore.kernel.org/all/20250304222018.615808-1-
>>>>> yang@...amperecomputing.com/
>>>>>
>>>>> Dev Jain (3):
>>>>>     mm: Allow pagewalk without locks
>>>>>     arm64: pageattr: Use walk_page_range_novma() to change memory
>>>>>       permissions
>>>>>     mm/pagewalk: Add pre/post_pte_table callback for lazy MMU on arm64
>>>>>
>>>>>    arch/arm64/mm/pageattr.c | 81 +++++++++++++++++++++++++++++++++++++---
>>>>>    include/linux/pagewalk.h |  4 ++
>>>>>    mm/pagewalk.c            | 18 +++++++--
>>>>>    3 files changed, 94 insertions(+), 9 deletions(-)
>>>>>

Powered by blists - more mailing lists