[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots

From: Peter Xu
Subject: Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots
Date: Fri, 12 Feb 2021 11:11:25 -0500

On Fri, Feb 12, 2021 at 09:52:52AM +0100, David Hildenbrand wrote:
> On 12.02.21 04:06, Peter Xu wrote:
> > On Thu, Feb 11, 2021 at 10:09:58PM +0100, David Hildenbrand wrote:
> > > The issue is when the discard happened before starting the snapshot. 
> > > Write-protection won‘t work and the zeroed content won‘t be retained in 
> > > the snapshot.
> > 
> > I see what you mean now, and iiuc it will only be a problem if 
> > init_on_free=1.
> > I think CONFIG_INIT_ON_FREE_DEFAULT_ON should be off for most distros, so 
> > the
> Yes, some distros seem to enable init_on_alloc instead. Looking at the
> introducing commit 6471384af2a6 ("mm: security: introduce init_on_alloc=1
> and init_on_free=1 boot options") there are security use cases and it might
> become important with memory tagging.
> Note that in Linux, there was also the option to poison pages with 0,
> removed via f289041ed4cf ("mm, page_poison: remove
> CONFIG_PAGE_POISONING_ZERO"), available in some kernels that supported free
> page reporting.
> It got removed and use cases got told to use init_on_free.
> > impact should be small, I think.  I thought about it, but indeed I didn't 
> > see a
> > good way to fix this if without fixing the zero page copy for live snapshot.
> We should really document this (unexpected) behavior of snapshotting.
> Otherwise, the next feature comes around that relies on pages that were
> discarded to remain zeroed (I even have one in mind ;) ) and forgets to
> disable snapshots.

Agreed.  I'll see whether Andrey would have any idea to workaround this, or
further comment.  Or I can draft a patch to document this next week (or unless
Andrey would beat me to it :).

Peter Xu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]