From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Vernon Yang <vernon2gm@gmail.com>,
akpm@linux-foundation.org, nico.pache@linux.dev,
ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org,
lance.yang@linux.dev, usama.arif@linux.dev, zokeefe@google.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Vernon Yang <yanglincheng@kylinos.cn>,
stable@vger.kernel.org
Subject: Re: [PATCH v2 2/3] mm: khugepaged: fix folio is used after pte_unmap_unlock()
Date: Mon, 17 Aug 2026 17:29:42 +0100 [thread overview]
Message-ID: <aoM10Z0wAKOMzsEO@lucifer> (raw)
In-Reply-To: <cd555188-2b51-4559-a315-0e8af6b2572a@kernel.org>
On Mon, Aug 17, 2026 at 06:20:02PM +0200, David Hildenbrand (Arm) wrote:
> On 8/17/26 18:11, Lorenzo Stoakes (ARM) wrote:
> > Same comment as 1/3 I don't see why we should be storing a pfn value used
> > nowhere else just for tracing.
>
> I prefer it that way. Even if just for tracing. :)
This is moot because you have to store the PFN for lifetime for museum-piece
architectures.
But anyway FWIW:
Yes I agree accessing a now-invalid folio isn't great, but the reason I dislike
this pattern is that you're tracking this state in a different way that now has
maintenance overhead (if anybody reassigns folio or does weird control flow
etc. they must now update 2 things and etc.)
For the sake of CONFIG_SPARSEMEM and tracing for a value that is not at all
intuitive as to what it means, that's not great.
Let me go back and review this again accounting for the lifetime issue that I
missed first time.
>
> --
> Cheers,
>
> David
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-08-17 16:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 5:19 [PATCH v2 0/3] mm: khugepaged: fix tracepoint UAF Vernon Yang
2026-08-15 5:19 ` [PATCH v2 1/3] mm: khugepaged: fix swap entry value to folio_pfn() Vernon Yang
2026-08-17 16:10 ` Lorenzo Stoakes (ARM)
2026-08-17 16:19 ` David Hildenbrand (Arm)
2026-08-17 16:24 ` Lorenzo Stoakes (ARM)
2026-08-17 16:23 ` Lorenzo Stoakes (ARM)
2026-08-15 5:19 ` [PATCH v2 2/3] mm: khugepaged: fix folio is used after pte_unmap_unlock() Vernon Yang
2026-08-17 16:11 ` Lorenzo Stoakes (ARM)
2026-08-17 16:20 ` David Hildenbrand (Arm)
2026-08-17 16:29 ` Lorenzo Stoakes (ARM) [this message]
2026-08-17 16:33 ` Lorenzo Stoakes
2026-08-15 5:19 ` [PATCH v2 3/3] mm: khugepaged: fix folio is used after folio_put/unlock() Vernon Yang
2026-08-15 17:44 ` [PATCH v2 0/3] mm: khugepaged: fix tracepoint UAF Lance Yang
2026-08-15 18:16 ` Lance Yang
2026-08-17 2:25 ` Baolin Wang
2026-08-17 2:53 ` Lance Yang
2026-08-17 7:24 ` Baolin Wang
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=aoM10Z0wAKOMzsEO@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nico.pache@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=stable@vger.kernel.org \
--cc=usama.arif@linux.dev \
--cc=vernon2gm@gmail.com \
--cc=yanglincheng@kylinos.cn \
--cc=zokeefe@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.