From nobody Tue Apr 7 22:01:45 2026 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC09F32E72F for ; Wed, 11 Mar 2026 14:04:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773237874; cv=none; b=t/a20SvZvsQ6hCr/mJdlGi/6JELIOYHySilnJe4xx1YSG+mEeC5vhgtXEKa4lNFQ4kVg1257d0D+jI7g/W0/FndDOgz80Y48rb/v/GvD3uMFqljrJlnZhhtgNcMFZljvompzyqXxEcKN06Sq4+ZRv7YZrtzP5xySDZwPr0gmvN4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773237874; c=relaxed/simple; bh=kZ9WWqrdIJV8UgKEgTeS/Qo0KzRPGBgiyXCeLRDIH98=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=H8aJWLCZ43BQMtJkXbqIaY4QEITu+q4GhmdojcF47AIggVaTOWE4k4yfRdBvgbbpNnTneeCqwB1h2XcUghS5LGSGgs6sFxYmomNsGyhAKkMAr0W+EmKbgfPm7dE7UsOniF2J8ECrXBy8zLYurWlzhJMOsBVVOdA8J1cRl2KRZZ4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=W1kLzIcU; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="W1kLzIcU" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-439db9da59eso4915104f8f.2 for ; Wed, 11 Mar 2026 07:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1773237871; x=1773842671; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=fEiNUz0Xgvwfo+PIGXYxM2gMpOXiJOFQGxw8KqZFCO0=; b=W1kLzIcUmFkUChwp+1h4toj9psr4tpg3rvpkU7BBebn3nbLiW/V7KxEkKb89wvSeSc QmRKbIeIXDfS6TJ8X+l+TABgW2Ir6EyXgkC6SSBkk3B/GIb8mR74OlV5yVLH5kH82GKL 4ynBT0j/eyJMiFwAE5yt5KFLSBReDgx4Tua/eUL2dISw1g9ihTbEfaaZa02Mxj6QWLFR oHaIk+9MIUk4qM/w8uC9uB4uGa89GYmrgnVOMUb8m0tdieoLdlLmFNcfoa+jOE0u+XwF 0YLzTEtmwkBVvi6cclp2Sh430TV3ZZZAM3TJhyJzrJ7J52//ZYIakp4wj6uKqTF+1V7i bEgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773237871; x=1773842671; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fEiNUz0Xgvwfo+PIGXYxM2gMpOXiJOFQGxw8KqZFCO0=; b=M+xBVKZa2p4w+55DrWg0HNCg2EF67WnmufsSgVBvYP8pZb15p7wmznzSsKLSmKsStR pYKASqxxrKhLPZLM/iZFyDgoy7Nhpo+u7sG55yoC9xPB6fCMNQ+ZKc+/llRTwdwCC5Rd UWd8U3UUmcFCxhWI7xCuuNeF/+clLBcKV/QO48yH8DvkEIsU2nFF5TID/zZ+39I6cEVe RAVC0ajaTJtiwij4Y2AgyRwXekgYTQsRgVlrgf12Oapdouz7rBSoYTHq62AaYsumDp+p 9ktTwacBpAg7AOtVcRLveCfc6x/hy1Y4f2H61OL5Tj4rZYBVH1QZVC4CsS/2LVQ5c3QJ fsQA== X-Gm-Message-State: AOJu0YxZMDsCP2pBxMFMKOZDp0QaVq6UGgn8QaEVv6FC6I+MH0I8WcIJ 6/OmH5HmLeHMjr1G2R8sZlYuy+Scxg87ToCSt+hefsqUK/WJkb43Y3sDT8wrUHwrbaIU/XeJIb3 xqI45pyWpL0sjKw== X-Received: from wrbgw30.prod.google.com ([2002:a05:6000:40de:b0:439:ac29:98cb]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:4028:b0:439:cb5c:b18d with SMTP id ffacd0b85a97d-439f821b64emr4992366f8f.38.1773237870887; Wed, 11 Mar 2026 07:04:30 -0700 (PDT) Date: Wed, 11 Mar 2026 14:04:24 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAGh2sWkC/x3MTQqAIBBA4avErBPUsL+rREToZAOpoRJBdPek5 bd474GEkTDBWD0Q8aJEwReIugK9r94iI1MMksuWN0Kw05rloJSZDs6hz0wiDl3ftVopCSU7I25 0/8tpft8PsSYJrmIAAAA= X-Change-Id: 20260311-pgd_list-comment-2ee97876c552 X-Mailer: b4 0.14.3 Message-ID: <20260311-pgd_list-comment-v1-1-4ea51b41adee@google.com> Subject: [PATCH] x86: fix location of comment about pgd_list From: Brendan Jackman To: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" Cc: linux-kernel@vger.kernel.org, Brendan Jackman Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 --- 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 */ =20 +/* + * 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 =3D virt_to_ptdesc(pgd); @@ -99,17 +109,6 @@ static void pgd_dtor(pgd_t *pgd) spin_unlock(&pgd_lock); } =20 -/* - * 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 (=3Dtlb flush) when --- base-commit: 8d3f80adf317848a3e07a8a34502498efe687b23 change-id: 20260311-pgd_list-comment-2ee97876c552 Best regards, --=20 Brendan Jackman