linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, Stephen Rothwell <sfr@canb.auug.org.au>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH v2] fs/proc/page: Skip uninitialized page when iterating page structures
Date: Mon, 26 Aug 2019 09:49:38 -0400	[thread overview]
Message-ID: <18a20b0f-7ceb-94db-b885-e63db45ebaa9@redhat.com> (raw)
In-Reply-To: <60464cac-6319-c3c1-47b8-d9b5cf586754@redhat.com>

On 8/26/19 9:43 AM, Waiman Long wrote:
> On 8/26/19 9:25 AM, Matthew Wilcox wrote:
>>
>> Would this not work equally well?
>>
>> +++ b/fs/proc/page.c
>> @@ -46,7 +46,8 @@ static ssize_t kpagecount_read(struct file *file, char __user *buf,
>>                         ppage = pfn_to_page(pfn);
>>                 else
>>                         ppage = NULL;
>> -               if (!ppage || PageSlab(ppage) || page_has_type(ppage))
>> +               if (!ppage || PageSlab(ppage) || page_has_type(ppage) ||
>> +                               PagePoisoned(ppage))
>>                         pcount = 0;
>>                 else
>>                         pcount = page_mapcount(ppage);
>>
> That is my initial thought too. However, I couldn't find out where the
> memory of the uninitialized page structures may have been initialized
> somehow. The only thing I found is when vm_debug is on that the page
> structures are indeed poisoned. Without that it is probably just
> whatever the content that the memory have when booting up the kernel.
>
> It just happens on the test system that I used the memory of those page
> structures turned out to be -1. It may be different in other systems
> that can still crash the kernel, but not detected by the PagePoisoned()
> check. That is why I settle on the current scheme which is more general
> and don't rely on the memory get initialized in a certain way.

Actually, I have also thought about always poisoning the page
structures. However, that will introduce additional delay in the boot up
process which can be problematic especially if the system has large
amount of persistent memory.

Cheers,
Longman



  reply	other threads:[~2019-08-26 13:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26 12:43 Waiman Long
2019-08-26 13:25 ` Matthew Wilcox
2019-08-26 13:43   ` Waiman Long
2019-08-26 13:49     ` Waiman Long [this message]
2019-08-26 14:20     ` Matthew Wilcox
2019-08-27 14:22 ` Michal Hocko
2019-08-28  8:00   ` Michal Hocko
2019-08-28 13:46     ` Waiman Long
2019-08-28 14:09       ` Michal Hocko
2019-08-28 14:18         ` Waiman Long
2019-08-29  1:47           ` Toshiki Fukasawa

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=18a20b0f-7ceb-94db-b885-e63db45ebaa9@redhat.com \
    --to=longman@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mst@redhat.com \
    --cc=sfr@canb.auug.org.au \
    --cc=willy@infradead.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