|
From: | David Hildenbrand |
Subject: | Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots |
Date: | Fri, 12 Feb 2021 09:52:52 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 |
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.
-- Thanks, David / dhildenb
[Prev in Thread] | Current Thread | [Next in Thread] |