On 4/8/25 10:40, Matthew Wilcox wrote:
> I think at this point in Kevin's series, we don't call the ctor for
> these pages, so we never set PageTable() on them. I could be wrong;
> as Kevin says, this is all very twisty and confusing with exceptions and
> exceptions to exceptions. This series sho
On Tue, Apr 08, 2025 at 09:54:42AM -0700, Dave Hansen wrote:
> On 4/8/25 09:37, Matthew Wilcox wrote:
> > On Tue, Apr 08, 2025 at 08:22:47AM -0700, Dave Hansen wrote:
> >> Are there any tests for folio_test_pgtable() at free_page() time? If we
> >> had that, it would make it less likely that anothe
On 4/8/25 09:37, Matthew Wilcox wrote:
> On Tue, Apr 08, 2025 at 08:22:47AM -0700, Dave Hansen wrote:
>> Are there any tests for folio_test_pgtable() at free_page() time? If we
>> had that, it would make it less likely that another free_page() user
>> could sneak in without calling the destructor.
On Tue, Apr 08, 2025 at 08:22:47AM -0700, Dave Hansen wrote:
> Are there any tests for folio_test_pgtable() at free_page() time? If we
> had that, it would make it less likely that another free_page() user
> could sneak in without calling the destructor.
It's hidden, but yes:
static inline bool p
On 4/8/25 02:52, Kevin Brodsky wrote:
> Page table pages are normally freed using the appropriate helper for
> the given page table level. On x86, pud_free_pmd_page() and
> pmd_free_pte_page() are an exception to the rule: they call
> free_page() directly.
>
> Constructor/destructor calls are abou
Constructors for PUD/P4D-level pgtables were recently introduced.
They should be called for all pgtables; make sure they are called
for special kernel mappings created by create_pgd_mapping() too.
While at it also switch to using pagetable_alloc() like
in alloc_{pte,pmd}_late().
Signed-off-by: Ke
Split page table locks are not used for pgtables associated to
init_mm, at any level. pte_alloc_kernel() does not call
ptlock_init() as a result. There is however no separate alloc/free
functions for kernel PMDs, and pmd_ptlock_init() is called
unconditionally. When ALLOC_SPLIT_PTLOCKS is true (e.g
Commit 90292aca9854 ("arm64: mm: use appropriate ctors for page
tables") introduced pgtable ctor calls in pgd_pgtable_alloc(). To
identify the pgtable level and call the appropriate ctor, the
*_SHIFT value associated with the pgtable level is used. However,
those values do not unambiguously identif
Constructors for PUD/P4D-level pgtables were recently introduced.
They should be called for all pgtables; make sure they are called
for special kernel mappings created by __create_pgd_mapping() too.
Signed-off-by: Kevin Brodsky
---
arch/arm64/mm/mmu.c | 6 +-
1 file changed, 5 insertions(+),
pagetable_{pte,pmd}_ctor(mm, ptdesc) skip the ptlock initialisation
if mm is &init_mm. To avoid unnecessary overhead, it is therefore
preferable to pass the actual mm associated to the PTE/PMD.
Unfortunately, this proves challenging for alloc_{pte,pmd}_late() as
the associated mm is not available
TL;DR: always call the PTE/PMD ctor, passing the appropriate mm to
skip ptlock_init() if unneeded.
__create_pgd_mapping() is used for creating different kinds of
mappings, and may allocate page table pages if passed an allocator
callback. There are currently three such cases:
1. create_pgd_mappin
There has been much confusion around exactly when page table
constructors/destructors (pagetable_*_[cd]tor) are supposed to be
called. They were initially introduced for user PTEs only (to support
split page table locks), then at the PMD level for the same purpose.
Accounting was added later on, st
Since [1], constructors/destructors are expected to be called for
all page table pages, at all levels and for both user and kernel
pgtables. There is however one glaring exception: kernel PTEs are
managed via separate helpers (pte_alloc_kernel/pte_free_kernel),
which do not call the [cd]tor, at lea
The generic implementation of pte_{alloc_one,free}_kernel now calls
the [cd]tor, without initialising the ptlock needlessly as
pagetable_pte_ctor() skips it for init_mm.
Align sparc64 with the generic implementation by ensuring
pagetable_pte_[cd]tor() are called for kernel PTEs. As a result
the ke
The generic implementation of pte_{alloc_one,free}_kernel now calls
the [cd]tor. Align the m68k/ColdFire implementation of those
functions by calling the [cd]tor explicitly.
Signed-off-by: Kevin Brodsky
---
arch/m68k/include/asm/mcf_pgalloc.h | 6 +-
1 file changed, 5 insertions(+), 1 deleti
In preparation for calling constructors for all kernel page tables
while eliding unnecessary ptlock initialisation, let's pass down the
associated mm to the PTE/PMD level ctors. (These are the two levels
where ptlocks are used.)
In most cases the mm is already around at the point of calling the
ct
The generic implementation of pte_{alloc_one,free}_kernel now calls
the [cd]tor, without initialising the ptlock needlessly as
pagetable_pte_ctor() skips it for init_mm.
On powerpc, all functions related to PTE allocation are implemented
by common helpers, which are passed a boolean to differentia
Page table pages are normally freed using the appropriate helper for
the given page table level. On x86, pud_free_pmd_page() and
pmd_free_pte_page() are an exception to the rule: they call
free_page() directly.
Constructor/destructor calls are about to be introduced for kernel
PTEs. To avoid missi
Hi Mike,
Le 14/03/2025 à 10:25, Christophe Leroy a écrit :
Le 13/03/2025 à 14:49, Mike Rapoport a écrit :
From: "Mike Rapoport (Microsoft)"
max_mapnr is essentially the size of the memory map for systems that use
FLATMEM. There is no reason to calculate it in each and every
architecture
w
19 matches
Mail list logo
