Re: [GIT PULL] x86/urgent for 7.4-rc4

[Linus Torvalds]

On Sun, 13 Sept 2026 at 17:18, Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>
> So the problem isn't with the data which was around at MADV_FREE time,
> it's with the "subsequent writes" that the kernel frees.  I _think_ the
> main way the kernel tells if a "subsequent write" occurs is _PAGE_DIRTY.

Yeah, so it looks to me like the *fix* is correct, and it's just that
blaming MADV_FREE is the wrong thing.

And if I read things right, this only happens for HUGETLB because the
normal page table code doesn't use pmd_modify(), so all the common
single-page cases get this right.

So it's really just pmd_modify() that is buggy, and the patch isn't
MADV_FREE, but probably something like

  mprotect_fixup ->
    change_protection ->
      change_protection_range ->
        change_p4d_range ->
          change_pud_range ->
            change_pmd_range ->
              change_pte_range ->
                change_huge_pmd ->
                  pmd_modify()

and the "Fixes:" line there in that commit looks correct too.

I still don't understand why that  whole

  & ~_PAGE_DIRTY

was added to that commit back in 2023 in the first place? The very
same commit did all the same changes to pte_modify() *EXCEPT* for that
dirty bit thing.

So the more I look at this, the more confused I am about why this happened.

The good news is that I think the fix is clearly correct. The thing I
reacted to was the misleading wording of the explanation.

This does not seem to be a bug in MADV_FREE at all, and isn't even
really related to MADV_FREE. I think MADV_FREE just happened to be a
way to trigger it.

And *maybe* MADV_FREE is the _only_ way to trigger it, but I'm not
even convinced about that part. It literally feels like mprotect() of
hugepages is really just buggy. It feels like that HUGEPAGE code
basically expected that "PAGE_RW" is always exactly the same as
"PAGE_DIRTY".

I dunno. Maybe I'm still missing something. But I did the pull, and I
just removed the comment blaming MADV_FREE, and I just rewrote it to
"THP not silently losing user data".

It still mentions MADV_FREE in the text that talks about having to
have a few things align. THAT part I can believe in: clearly something
has to align just right for this to actually be a user-visible issue,
explaining why it wasn't an obvious bug.

I'd love for somebody to hit me with a clue hammer on how this all
happened, but I guess that's not required for the fix.

            Linus