Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support

On Tue, May 26, 2026 at 06:07:38AM -0600, Nico Pache wrote:

On Tue, May 26, 2026 at 12:57 AM Wei Yang [off-list ref] wrote:

quoted

On Mon, May 25, 2026 at 12:10:41PM -0700, Andrew Morton wrote:

quoted

On Mon, 25 May 2026 08:15:53 -0600 Nico Pache [off-list ref] wrote:

quoted

Can you please append the following fixup that reverts one of the
changes requested in V17. The issue with the change is described
below.

OK.  fyi, what I received was badly mangled: wordwrapping, tabs messed
up, etc.

Here's my reconstruction:

Hi, Nico

I tried to reply your mail, but found it has some encoding problem, so reply
here.

Yeah sorry I didnt properly configure my email client after getting a
new laptop.

quoted

quoted

Author: Nico Pache [off-list ref]
Subject: fix potential use-after-free of vma in mthp_collapse()
Date: Mon May 25 07:38:59 2026 -0600

Between V17 and v18, one reviewer (Wei) brought up that we are not doing
the uffd-armed check until deep in the collapse operation.  While not
functionally incorrect, it can lead to unnecessary work.

So we decide to tolerate the behavioral change?

Yes, I believe it is ok for now. Either way we needed to remove the
potential UAF. It only affects the behavior if mTHP is enabled, so the
legacy behavior is kept. And the uffd case is limited.

My future work involves further optimizing and cleaning up khugepaged.
I'll make this part of the goal too. My first thought is to do the
revalidation at every order (between the locks dropping); but that
essentially pays the same penalty... I can't think of a clean solution
at the moment.

One way come into my mind is add a @was_uffd_armed field in collapse_control
and updates it in hugepage_vma_revalidate() when latest vma is retrieved.

Still not elegant enough.

Does that sound ok?

Not sure. I can't imagine the impact it would have.

Cheers,
-- Nico

-- 
Wei Yang
Help you, Help me