Re: [PATCH 0/5] Improve page poisoning implementation

[John Hubbard <jhubbard@nvidia.com>]

On 4/8/20 8:11 AM, Pavel Tatashin wrote:
> On Wed, Apr 8, 2020 at 11:01 AM Matthew Wilcox <willy@infradead.org> wrote:
>>
>> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>>
>> I really don't like that this feature is called page poisoning.
>> We already had something called page poisoning and it's when you detect
>> a memory error in a page.  This is just uninitialised pages.  I don't
> 
> Hi Matthew,
> 
> Thank you for working on this. Uninitialized struct pages are often
> zeroed by firmware, and there were a number of implicit assumptions
> about that memory when I worked on deferred page initializations, this
> is why it is important to also test when struct pages are specifically
> set to a pattern that is not all zeroes, something that can happen
> during kexec, or when memory allocated and freed by kernel during
> boot. We have caught a good number of bugs using this mechanism. So,
> this is poisoning, but I agree "page poisoning" name is misleading, as
> we have this term used in another place. So, lets agree on a better
> term: how about memmap poisoning (s/page_poisoning/memmap_poisoning/)?
> 

Better to avoid the "poison" word entirely. It's just too well-established
as a hardware memory error case. Early ideas for other names, just to get
started: use "uninitialize" or "deinitialize" instead of "poison".
So approximately:

	page_deinit
	page_deinitialize
	page_uninit
	page_uninitialize
	mem_deinit
	...other variations...	

thanks,
-- 
John Hubbard
NVIDIA