mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: ljs@kernel.org, akpm@linux-foundation.org
Cc: david@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com,
	liam@infradead.org, nico.pache@linux.dev, ryan.roberts@arm.com,
	dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev,
	usama.arif@linux.dev, kas@kernel.org, guoren@kernel.org,
	bcain@kernel.org, geert@linux-m68k.org, dinguyen@kernel.org,
	schuster.simon@siemens-energy.com, jonas@southpole.se,
	stefan.kristiansson@saunalahti.fi, shorne@gmail.com,
	dalias@libc.org, glaubitz@physik.fu-berlin.de, pjw@kernel.org,
	palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
	linux@armlinux.org.uk, vgupta@kernel.org, monstr@monstr.eu,
	chris@zankel.net, jcmvbkbc@gmail.com, will@kernel.org,
	aneesh.kumar@kernel.org, npiggin@gmail.com, peterz@infradead.org,
	davem@davemloft.net, andreas@gaisler.com,
	richard.henderson@linaro.org, mattst88@gmail.com,
	linmag7@gmail.com, catalin.marinas@arm.com, mark.rutland@arm.com,
	chenhuacai@kernel.org, kernel@xen0n.name,
	tsbogend@alpha.franken.de, James.Bottomley@hansenpartnership.com,
	deller@gmx.de, maddy@linux.ibm.com, mpe@ellerman.id.au,
	chleroy@kernel.org, hca@linux.ibm.com, gor@linux.ibm.com,
	agordeev@linux.ibm.com, borntraeger@linux.ibm.com,
	svens@linux.ibm.com, richard@nod.at,
	anton.ivanov@cambridgegreys.com, johannes@sipsolutions.net,
	tglx@kernel.org, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
	arnd@arndb.de, vbabka@kernel.org, rppt@kernel.org,
	surenb@google.com, mhocko@suse.com, jgg@ziepe.ca,
	jhubbard@nvidia.com, peterx@redhat.com,
	ysato@users.sourceforge.jp, shakeel.butt@linux.dev,
	corbet@lwn.net, rdunlap@infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-csky@vger.kernel.org,
	linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
	linux-openrisc@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-snps-arc@lists.infradead.org, linux-arch@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-alpha@vger.kernel.org,
	loongarch@lists.linux.dev, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-um@lists.infradead.org,
	hughd@google.com, qi.zheng@linux.dev, linux-doc@vger.kernel.org
Subject: Re: [PATCH v4 01/12] mm/khugepaged: deposit a newly allocated page table on collapse
Date: Wed, 23 Sep 2026 15:24:00 +0800	[thread overview]
Message-ID: <20260923072400.3028-1-lance.yang@linux.dev> (raw)
In-Reply-To: <arN7q5nHz7iebA_e@gremlin>


On Wed, Sep 23, 2026 at 08:14:01AM +0100, Lorenzo Stoakes (ARM) wrote:
>Andrew - would it be possible to make one quick fix up below?
>
>On Tue, Sep 22, 2026 at 04:35:32PM +0100, Lorenzo Stoakes (ARM) wrote:
>> collapse_huge_page() deposits a PTE page table on PMD collapse in order
>> that it can be utilised for subsequent split operations, meaning that those
>> operations do not need to perform an allocation (as they are in a context
>> where it might be unwise).
>>
>> However the PTE page table which is deposited is the one which is currently
>> mapped by the PMD entry that is in the process of being collapsed.
>>
>> Once deposited, the PTE page table may be used in a split of any other
>> unrelated PMD entry.
>>
>> This is currently not an issue as this operation is performed with VMA/mmap
>> write lock + anon rmap locks held, so ordinary page table walkers will
>> never accidentally end up walking the wrong thing, and GUP-fast is
>> protected by an IPI via tlb_remove_table_sync_one().
>>
>> However, the series to which this commit belongs implements RCU-safe page
>> table traversal, at which point this becomes problematic.
>>
>> This can be resolved by using pte_offset_map_lock() which gates on a PTE
>> PTL and a pmd_same() check, but lockless walks are unsafe as things stand.
>>
>> Resolve this by simply allocating a new, zeroed, PTE page table to deposit
>> at the point of collapse.
>>
>> This path is already costly and an allocation has already been performed
>> for the huge folio, so this allocation is statistical noise in terms of
>> performance and memory usage at this point.
>>
>> With this PTE page table deposited, RCU-free the existing PTE page table
>> so it is safe for page table walkers to traverse within a grace period.
>>
>> This also brings this deposit case in line with all other page table
>> deposit logic which deposit a fresh page table.
>>
>> Additionally, this was the only place in the kernel that displaced a page
>> table like this, so eliminating it also helps consistency.
>>
>> An edge case for deposit exists for powerpc and its hash-based MMU - it
>> stores hash slot data in deposited page tables and zeroes them on withdraw,
>> so a zeroed deposited page table works correctly for it.
>>
>> Since khugepaged runs as a kernel thread, do a little dance in
>> alloc_deposit_pte() to correctly charge the allocation.
>>
>> This is already done for the folio allocation via alloc_charge_folio() but
>> no such wrapper exists for a page table allocation.
>>
>> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>> ---
>>  mm/khugepaged.c | 32 ++++++++++++++++++++++++++++++--
>>  1 file changed, 30 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> index f49a6710933b..dab421f8233e 100644
>> --- a/mm/khugepaged.c
>> +++ b/mm/khugepaged.c
>> @@ -1278,6 +1278,23 @@ static enum scan_result alloc_charge_folio(struct folio **foliop, struct mm_stru
>>  	return SCAN_SUCCEED;
>>  }
>>
>> +static pgtable_t alloc_deposit_pte(struct mm_struct *mm)
>> +{
>> +	/*
>> +	 * khugepaged is run from a kernel thread, so need to manually set the
>> +	 * correct memcg so the allocation gets charged correctly.
>> +	 */
>> +	struct mem_cgroup *memcg = get_mem_cgroup_from_mm(mm);
>> +	struct mem_cgroup *old_memcg = set_active_memcg(memcg);
>> +	pgtable_t pgtable;
>> +
>> +	pgtable = pte_alloc_one(mm);
>> +
>> +	set_active_memcg(old_memcg);
>> +	mem_cgroup_put(memcg);
>> +	return pgtable;
>> +}
>> +
>>  /*
>>   * collapse_huge_page() expects the mmap_lock to be unlocked before entering and
>>   * will always return with the lock unlocked, to avoid holding the mmap_lock
>> @@ -1293,7 +1310,7 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
>>  	LIST_HEAD(compound_pagelist);
>>  	pmd_t *pmd, _pmd;
>>  	pte_t *pte = NULL;
>> -	pgtable_t pgtable;
>> +	pgtable_t pgtable = NULL;
>>  	struct folio *folio;
>>  	spinlock_t *pmd_ptl, *pte_ptl;
>>  	enum scan_result result = SCAN_FAIL;
>> @@ -1310,6 +1327,12 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long s
>>  		goto out_nolock;
>>  	}
>>
>> +	if (is_pmd_order(order)) {
>> +		pgtable = alloc_deposit_pte(mm);
>> +		if (!pgtable)
>> +			goto out_nolock;
>
>Fixup is here:
>
>-		if (!pgtable)
>-			goto out_nolock;
>+		if (!pgtable) {
>+			result = SCAN_ALLOC_HUGE_PAGE_FAIL;
>+			goto out_nolock;
>+		}
>
>Thanks!

With that applied,

Reviewed-by: Lance Yang <lance.yang@linux.dev>

  reply	other threads:[~2026-09-23  7:24 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 15:35 [PATCH v4 00/12] mm: make userland page table freeing RCU-safe Lorenzo Stoakes (ARM)
2026-09-22 15:35 ` [PATCH v4 01/12] mm/khugepaged: deposit a newly allocated page table on collapse Lorenzo Stoakes (ARM)
2026-09-23  2:24   ` Lance Yang
2026-09-23  7:09     ` Lorenzo Stoakes (ARM)
2026-09-23  7:14   ` Lorenzo Stoakes (ARM)
2026-09-23  7:24     ` Lance Yang [this message]
2026-09-23 19:53     ` Andrew Morton
2026-09-23  8:54   ` David Hildenbrand (Arm)
2026-09-23  9:00     ` Lorenzo Stoakes (ARM)
2026-09-22 15:35 ` [PATCH v4 02/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for most 2-level architectures Lorenzo Stoakes (ARM)
2026-09-23  4:39   ` Lance Yang
2026-09-22 15:35 ` [PATCH v4 03/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for MMU riscv Lorenzo Stoakes (ARM)
2026-09-23  6:15   ` Lance Yang
2026-09-23  7:05     ` Lorenzo Stoakes (ARM)
2026-09-23  7:17       ` Lance Yang
2026-09-22 15:35 ` [PATCH v4 04/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for MMU arm Lorenzo Stoakes (ARM)
2026-09-23  8:05   ` Lance Yang
2026-09-23  8:15     ` Lorenzo Stoakes (ARM)
2026-09-22 15:35 ` [PATCH v4 05/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for arc, microblaze, xtensa Lorenzo Stoakes (ARM)
2026-09-23  8:43   ` Lance Yang
2026-09-22 15:35 ` [PATCH v4 06/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for sparc64 Lorenzo Stoakes (ARM)
2026-09-23  8:54   ` Lance Yang
2026-09-22 15:35 ` [PATCH v4 07/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for m68k-coldfire Lorenzo Stoakes (ARM)
2026-09-23  9:13   ` Lance Yang
2026-09-23 11:31   ` Greg Ungerer
2026-09-23 11:36     ` Lorenzo Stoakes (ARM)
2026-09-22 15:35 ` [PATCH v4 08/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for sh-X2 Lorenzo Stoakes (ARM)
2026-09-23 11:54   ` Lance Yang
2026-09-23 11:56     ` Lorenzo Stoakes (ARM)
2026-09-22 15:35 ` [PATCH v4 09/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for m68k-motorola Lorenzo Stoakes (ARM)
2026-09-23 13:16   ` Lance Yang
2026-09-23 13:21     ` Lorenzo Stoakes (ARM)
2026-09-22 15:35 ` [PATCH v4 10/12] mm: enable MMU_GATHER_RCU_TABLE_FREE for sparc32 Lorenzo Stoakes (ARM)
2026-09-22 15:35 ` [PATCH v4 11/12] mm: make userland page table freeing RCU-safe Lorenzo Stoakes (ARM)
2026-09-23  9:04   ` David Hildenbrand (Arm)
2026-09-23  9:06     ` Lorenzo Stoakes (ARM)
2026-09-23  9:13       ` David Hildenbrand (Arm)
2026-09-23 11:48         ` Lorenzo Stoakes (ARM)
2026-09-23 13:38           ` David Hildenbrand (Arm)
2026-09-23 13:43             ` Lorenzo Stoakes (ARM)
2026-09-22 15:35 ` [PATCH v4 12/12] mm: change the contract for free_pgtables(), update docs Lorenzo Stoakes (ARM)
2026-09-23  9:08   ` David Hildenbrand (Arm)
2026-09-23 11:55     ` Lorenzo Stoakes (ARM)
2026-09-22 16:42 ` [PATCH v4 00/12] mm: make userland page table freeing RCU-safe Matthew Wilcox
2026-09-22 17:22   ` Lorenzo Stoakes (ARM)
2026-09-22 23:00 ` Andrew Morton
2026-09-23  7:04   ` Lorenzo Stoakes (ARM)
2026-09-23 20:01     ` Andrew Morton
2026-09-23  8:45   ` David Hildenbrand (Arm)
2026-09-23  9:04     ` Lorenzo Stoakes (ARM)
2026-09-23  9:15       ` David Hildenbrand (Arm)
2026-09-23  9:39         ` Vlastimil Babka (SUSE)
2026-09-23 11:39           ` Lorenzo Stoakes (ARM)
2026-09-23 19:59 ` Andrew Morton

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=20260923072400.3028-1-lance.yang@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=andreas@gaisler.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bcain@kernel.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=chleroy@kernel.org \
    --cc=chris@zankel.net \
    --cc=corbet@lwn.net \
    --cc=dalias@libc.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=david@kernel.org \
    --cc=deller@gmx.de \
    --cc=dev.jain@arm.com \
    --cc=dinguyen@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=gor@linux.ibm.com \
    --cc=guoren@kernel.org \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=johannes@sipsolutions.net \
    --cc=jonas@southpole.se \
    --cc=kas@kernel.org \
    --cc=kernel@xen0n.name \
    --cc=liam@infradead.org \
    --cc=linmag7@gmail.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-openrisc@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ljs@kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=maddy@linux.ibm.com \
    --cc=mark.rutland@arm.com \
    --cc=mattst88@gmail.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=monstr@monstr.eu \
    --cc=mpe@ellerman.id.au \
    --cc=nico.pache@linux.dev \
    --cc=npiggin@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pjw@kernel.org \
    --cc=qi.zheng@linux.dev \
    --cc=rdunlap@infradead.org \
    --cc=richard.henderson@linaro.org \
    --cc=richard@nod.at \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=schuster.simon@siemens-energy.com \
    --cc=shakeel.butt@linux.dev \
    --cc=shorne@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=surenb@google.com \
    --cc=svens@linux.ibm.com \
    --cc=tglx@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=vgupta@kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=ysato@users.sourceforge.jp \
    --cc=ziy@nvidia.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

all inboxes | Powered by JetHome®