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

[Dave Hansen <dave.hansen@intel.com>]

On 9/13/26 16:10, Linus Torvalds wrote:
> On Sun, 13 Sept 2026 at 15:54, Dave Hansen <dave.hansen@linux.intel.com> wrote:
>> The MADV_FREE one is notable for silently losing user data and having
>> been around for a couple of years.
> That explanation rewards horribly badly.
> 
> MADV_FREE itself is fine. It's *supposed* to drop dirty bits and lose
> user data. That is the whole -m and only - point of MADV_FREE in the
> first place.
> 
> The bug seems to be elsewhere in non-MADV_FREE code that then just is
> confused about things. But both your pull request and that commit
> message seem to try to blame MADV_FREE. What's up?

Yeah, the explanation isn't great. Sorry about that.

My read on it is that problem shows up a bit *after* the actual
MADV_FREE. The manpage goes over this scenario:

	After a successful MADV_FREE operation, any stale data
	(i.e.,  dirty, unwritten pages) will be lost when the kernel
	frees the pages. However, subsequent writes to pages in the
	range will succeed and then kernel cannot free those dirtied
	pages, so that the caller can always see just written data.

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.

So the scenario is something like this:

 1. First set of data goes into the page
 2. MADV_FREE performed, clears _PAGE_DIRTY. Page eligible for reclaim.
 3. Second set of data is written, sets _PAGE_DIRTY. Page *in*eligible
    for reclaim.
 4. PMD is mprotect()'d which flows through pmd_modify(). _PAGE_DIRTY
    is lost. Page now wrongly eligible for reclaim again.
 5. Reclaim goes after the page, discards second set of data.

At least that was my read on it.