[PATCH] x86: fix location of comment about pgd_list

[PATCH] x86: fix location of comment about pgd_list

[Brendan Jackman]

This venerable comment got detached from its context when the code moved
in commit 394158559d4c ("x86: move all the pgd_list handling to one
place"). Put it back next to that code.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
I think there are a couple of other issues with this comment:

1. pageattr.c doesn't exist any more.

2. I believe the lazy vmalloc fault thing it's talking about doesn't
   exist any more.

I don't know how to clarify the pageattr.c thing. Unless anyone can help
there, I'd propose to just delete the second half of this comment. But
will wait in case anyone can correct me on the vmalloc thing.
---
 arch/x86/mm/pgtable.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 2e5ecfdce73c3..bb59eb2700002 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -55,6 +55,16 @@ void ___p4d_free_tlb(struct mmu_gather *tlb, p4d_t *p4d)
 #endif	/* CONFIG_PGTABLE_LEVELS > 3 */
 #endif	/* CONFIG_PGTABLE_LEVELS > 2 */
 
+/*
+ * List of all pgd's needed for non-PAE so it can invalidate entries
+ * in both cached and uncached pgd's; not needed for PAE since the
+ * kernel pmd is shared. If PAE were not to share the pmd a similar
+ * tactic would be needed. This is essentially codepath-based locking
+ * against pageattr.c; it is the unique case in which a valid change
+ * of kernel pagetables can't be lazily synchronized by vmalloc faults.
+ * vmalloc faults work because attached pagetables are never freed.
+ * -- nyc
+ */
 static inline void pgd_list_add(pgd_t *pgd)
 {
 	struct ptdesc *ptdesc = virt_to_ptdesc(pgd);
@@ -99,17 +109,6 @@ static void pgd_dtor(pgd_t *pgd)
 	spin_unlock(&pgd_lock);
 }
 
-/*
- * List of all pgd's needed for non-PAE so it can invalidate entries
- * in both cached and uncached pgd's; not needed for PAE since the
- * kernel pmd is shared. If PAE were not to share the pmd a similar
- * tactic would be needed. This is essentially codepath-based locking
- * against pageattr.c; it is the unique case in which a valid change
- * of kernel pagetables can't be lazily synchronized by vmalloc faults.
- * vmalloc faults work because attached pagetables are never freed.
- * -- nyc
- */
-
 #ifdef CONFIG_X86_PAE
 /*
  * In PAE mode, we need to do a cr3 reload (=tlb flush) when

---
base-commit: 8d3f80adf317848a3e07a8a34502498efe687b23
change-id: 20260311-pgd_list-comment-2ee97876c552

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>

Re: [PATCH] x86: fix location of comment about pgd_list

[Dave Hansen]

On 3/11/26 07:04, Brendan Jackman wrote:
> This venerable comment got detached from its context when the code moved
> in commit 394158559d4c ("x86: move all the pgd_list handling to one
> place"). Put it back next to that code.

Shouldn't the comment about the data structure be on the *data*
*structure*, not the code?

	LIST_HEAD(pgd_list);

?

But either way, I think the comment should just be chopped down to
something much smaller, maybe:

	/*
	 * A list of all PGD pages. Mainly used to keep shared kernel
	 * mapping page tables in sync. Needed because PGDs are private
	 * to each process.
	 */

Re: [PATCH] x86: fix location of comment about pgd_list

[Brendan Jackman]

On Wed Mar 11, 2026 at 4:39 PM UTC, Dave Hansen wrote:
> On 3/11/26 07:04, Brendan Jackman wrote:
>> This venerable comment got detached from its context when the code moved
>> in commit 394158559d4c ("x86: move all the pgd_list handling to one
>> place"). Put it back next to that code.
>
> Shouldn't the comment about the data structure be on the *data*
> *structure*, not the code?
>
> 	LIST_HEAD(pgd_list);
>
> ?

Yep, you're right.

>
> But either way, I think the comment should just be chopped down to
> something much smaller, maybe:
>
> 	/*
> 	 * A list of all PGD pages. Mainly used to keep shared kernel
> 	 * mapping page tables in sync. Needed because PGDs are private
> 	 * to each process.
> 	 */

Great, sounds good to me. I'll let this sit a little in case anyone has
other additions/corrections then post a v2.