From: Laura Abbott <labbott@redhat.com>
To: Vinayak Menon <vinmenon@codeaurora.org>,
iamjoonsoo.kim@lge.com, mhocko@suse.com,
akpm@linux-foundation.org
Cc: shashim@codeaurora.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: enable page poisoning early at boot
Date: Wed, 29 Mar 2017 10:14:04 -0700 [thread overview]
Message-ID: <765ba1d2-d273-e4b1-7ec2-523fe2784ae2@redhat.com> (raw)
In-Reply-To: <d9e8b184-b2a9-1174-4a6b-17ae1d2d6444@redhat.com>
On 03/29/2017 10:04 AM, Laura Abbott wrote:
> On 03/24/2017 05:24 AM, Vinayak Menon wrote:
>> On SPARSEMEM systems page poisoning is enabled after buddy is up, because
>> of the dependency on page extension init. This causes the pages released
>> by free_all_bootmem not to be poisoned. This either delays or misses
>> the identification of some issues because the pages have to undergo another
>> cycle of alloc-free-alloc for any corruption to be detected.
>> Enable page poisoning early by getting rid of the PAGE_EXT_DEBUG_POISON
>> flag. Since all the free pages will now be poisoned, the flag need not be
>> verified before checking the poison during an alloc.
>>
>> Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
>> ---
>>
>> An RFC was sent earlier (http://www.spinics.net/lists/linux-mm/msg123142.html)
>> Not sure if there exists a code path that can free pages to buddy skipping
>> kernel_poison_pages, making the flag PAGE_EXT_DEBUG_POISON a necessity. But
>> the tests have not shown any issues. As per Laura's suggestion, the patch was
>> tested with HIBERNATION enabled and no issues were seen.
>>
>
> I gave this a spin on some of my machines and it appears to be working
> okay. I wish we had a bit more context about why it was necessary to track
> the poison in the page itself.
>
> This change means that we shouldn't need the "select PAGE_EXTENSION"
> anymore so that can be dropped. If you do that, you can add
>
> Acked-by: Laura Abbott <labbott@redhat.com>
>
Actually never mind on dropping the select. It's still needed for
the guard page as well. Longer term it might be worth separating
that out as well.
You can still take my Ack.
Thanks,
Laura
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-03-29 17:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 12:24 Vinayak Menon
2017-03-29 17:04 ` Laura Abbott
2017-03-29 17:14 ` Laura Abbott [this message]
2017-03-30 12:45 ` Vinayak Menon
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=765ba1d2-d273-e4b1-7ec2-523fe2784ae2@redhat.com \
--to=labbott@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shashim@codeaurora.org \
--cc=vinmenon@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox