All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/2] mm: memfd_luo: always dirty all folios
Date: Thu, 5 Mar 2026 12:40:43 +0200	[thread overview]
Message-ID: <aaldqxw90rdwCt6p@kernel.org> (raw)
In-Reply-To: <2vxzv7fabr84.fsf@kernel.org>

On Thu, Mar 05, 2026 at 09:44:27AM +0100, Pratyush Yadav wrote:
> Hi Mike,
> 
> On Wed, Feb 25 2026, Mike Rapoport wrote:
> 
> > On Mon, Feb 23, 2026 at 06:39:29PM +0100, Pratyush Yadav wrote:
> [...]
> >> -		if (folio_test_dirty(folio))
> >> -			flags |= MEMFD_LUO_FOLIO_DIRTY;
> >> +		/*
> >> +		 * A dirty folio is one which has been written to. A clean folio
> >> +		 * is its opposite. Since a clean folio does not carry user
> >> +		 * data, it can be freed by page reclaim under memory pressure.
> >> +		 *
> >> +		 * Saving the dirty flag at prepare() time doesn't work since it
> >> +		 * can change later. Saving it at freeze() also won't work
> >> +		 * because the dirty bit is normally synced at unmap and there
> >> +		 * might still be a mapping of the file at freeze().
> >> +		 *
> >> +		 * To see why this is a problem, say a folio is clean at
> >> +		 * preserve, but gets dirtied later. The pfolio flags will mark
> >> +		 * it as clean. After retrieve, the next kernel might try to
> >> +		 * reclaim this folio under memory pressure, losing user data.
> >> +		 *
> >> +		 * Unconditionally mark it dirty to avoid this problem. This
> >> +		 * comes at the cost of making clean folios un-reclaimable after
> >> +		 * live update.
> >> +		 */
> >
> > Can we make the comment here shorter to only contain the gist of the issue?
> 
> Is this any better? Or should I try to make it shorter still?

Yep, thanks! :)

I don't think it can be made shorter without loosing information. What we
might do is to add a larger comment in what state we preserve folios on top
of memfd_luo_preserve_folios() and leave the code inside the function
alone. Can't say I have strong feelings about it.
 
> 	/*
> 	 * Tracking the dirty flag of the folio is difficult since it is
> 	 * normally synced at unmap and there might still be mappings of
> 	 * the file alive.
> 	 *
> 	 * Not tracking it correctly can cause a dirty folio to be
> 	 * restored as clean after KHO. The next kernel might then try
> 	 * to reclaim it, losing user data.
> 	 *
> 	 * Unconditionally mark the folio dirty to avoid this. This
> 	 * comes at the cost of making clean folios un-reclaimable.
> 	 */
> 
> [...]
> 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.


      reply	other threads:[~2026-03-05 10:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 17:39 [PATCH 0/2] mm: memfd_luo: fixes for folio flag preservation Pratyush Yadav
2026-02-23 17:39 ` [PATCH 1/2] mm: memfd_luo: always make all folios uptodate Pratyush Yadav
2026-02-25  8:53   ` Mike Rapoport
2026-03-05  8:50     ` Pratyush Yadav
2026-03-06 15:44       ` Mike Rapoport
2026-02-23 17:39 ` [PATCH 2/2] mm: memfd_luo: always dirty all folios Pratyush Yadav
2026-02-25  8:58   ` Mike Rapoport
2026-03-05  8:44     ` Pratyush Yadav
2026-03-05 10:40       ` Mike Rapoport [this message]

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=aaldqxw90rdwCt6p@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=stable@vger.kernel.org \
    /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.