From: Cody P Schafer <cody@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
Valdis.Kletnieks@vt.edu
Subject: Re: [PATCH] mm/page_alloc: don't re-init pageset in zone_pcp_update()
Date: Wed, 12 Jun 2013 14:45:52 -0700 [thread overview]
Message-ID: <51B8EC10.6070304@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130612142032.882a28b7911ed24ca19e282e@linux-foundation.org>
On 06/12/2013 02:20 PM, Andrew Morton wrote:
> On Tue, 11 Jun 2013 15:12:59 -0700 Cody P Schafer <cody@linux.vnet.ibm.com> wrote:
>
>> Factor pageset_set_high_and_batch() (which contains all needed logic too
>> set a pageset's ->high and ->batch inrespective of system state) out of
>> zone_pageset_init(), which avoids us calling pageset_init(), and
>> unsafely blowing away a pageset at runtime (leaked pages and
>> potentially some funky allocations would be the result) when memory
>> hotplug is triggered.
>
> This changelog is pretty screwed up :( It tells us what the patch does
> but not why it does it.
>
It says why it does it, though perhaps a bit hidden:
> avoids us calling pageset_init(), and unsafely blowing away a pageset
>> Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
>> ---
>>
>> Unless memory hotplug is being triggered on boot, this should *not* be cause of Valdis
>> Kletnieks' reported bug in -next:
>> "next-20130607 BUG: Bad page state in process systemd pfn:127643"
>
> And this addendum appears to hint at the info we need.
Note the *not*. I included this note only because I expected there would
be a question of whether Valdis's reported bug was caused by this. It
_isn't_. The bug this fix fixes is only triggered by memory_hotplug, and
Valdis's bug occurred on boot.
> Please, send a new changelog? That should include a description of the
> user-visible effects of the bug which is being fixed, a description of
> why it occurs and a description of how it was fixed.It would also be
> helpful if you can identify which kernel version(s) need the fix.
It's just a -mm issue. It was introduced by my patchset starting with
"mm/page_alloc: factor out setting of pcp->high and pcp->batch", where
the actual place the bug snuck in was "mm/page_alloc: in
zone_pcp_update(), uze zone_pageset_init()".
>
> Also, a Reported-by:Valdis would be appropriate.
>
I'm fine with adding it (I did take a look at my page_alloc.c changes
because he reported that bug), but as mentioned before, this fixes a
different bug.
Anyhow, a reorganized (and clearer) changelog with the same content follows:
---
mm/page_alloc: don't re-init pageset in zone_pcp_update()
When memory hotplug is triggered, we call pageset_init() on a
per-cpu-pageset which both contains pages and is in use, causing both
the leakage of those pages and (potentially) bad behaviour if a page is
allocated from the pageset while it is being cleared.
Avoid this by factoring pageset_set_high_and_batch() (which contains all
needed logic too set a pageset's ->high and ->batch inrespective of
system state), and using that instead of zone_pageset_init() in
zone_pcp_update().
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Cody P Schafer <cody@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
Valdis.Kletnieks@vt.edu
Subject: Re: [PATCH] mm/page_alloc: don't re-init pageset in zone_pcp_update()
Date: Wed, 12 Jun 2013 14:45:52 -0700 [thread overview]
Message-ID: <51B8EC10.6070304@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130612142032.882a28b7911ed24ca19e282e@linux-foundation.org>
On 06/12/2013 02:20 PM, Andrew Morton wrote:
> On Tue, 11 Jun 2013 15:12:59 -0700 Cody P Schafer <cody@linux.vnet.ibm.com> wrote:
>
>> Factor pageset_set_high_and_batch() (which contains all needed logic too
>> set a pageset's ->high and ->batch inrespective of system state) out of
>> zone_pageset_init(), which avoids us calling pageset_init(), and
>> unsafely blowing away a pageset at runtime (leaked pages and
>> potentially some funky allocations would be the result) when memory
>> hotplug is triggered.
>
> This changelog is pretty screwed up :( It tells us what the patch does
> but not why it does it.
>
It says why it does it, though perhaps a bit hidden:
> avoids us calling pageset_init(), and unsafely blowing away a pageset
>> Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
>> ---
>>
>> Unless memory hotplug is being triggered on boot, this should *not* be cause of Valdis
>> Kletnieks' reported bug in -next:
>> "next-20130607 BUG: Bad page state in process systemd pfn:127643"
>
> And this addendum appears to hint at the info we need.
Note the *not*. I included this note only because I expected there would
be a question of whether Valdis's reported bug was caused by this. It
_isn't_. The bug this fix fixes is only triggered by memory_hotplug, and
Valdis's bug occurred on boot.
> Please, send a new changelog? That should include a description of the
> user-visible effects of the bug which is being fixed, a description of
> why it occurs and a description of how it was fixed.It would also be
> helpful if you can identify which kernel version(s) need the fix.
It's just a -mm issue. It was introduced by my patchset starting with
"mm/page_alloc: factor out setting of pcp->high and pcp->batch", where
the actual place the bug snuck in was "mm/page_alloc: in
zone_pcp_update(), uze zone_pageset_init()".
>
> Also, a Reported-by:Valdis would be appropriate.
>
I'm fine with adding it (I did take a look at my page_alloc.c changes
because he reported that bug), but as mentioned before, this fixes a
different bug.
Anyhow, a reorganized (and clearer) changelog with the same content follows:
---
mm/page_alloc: don't re-init pageset in zone_pcp_update()
When memory hotplug is triggered, we call pageset_init() on a
per-cpu-pageset which both contains pages and is in use, causing both
the leakage of those pages and (potentially) bad behaviour if a page is
allocated from the pageset while it is being cleared.
Avoid this by factoring pageset_set_high_and_batch() (which contains all
needed logic too set a pageset's ->high and ->batch inrespective of
system state), and using that instead of zone_pageset_init() in
zone_pcp_update().
Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
next prev parent reply other threads:[~2013-06-12 21:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 22:12 [PATCH] mm/page_alloc: don't re-init pageset in zone_pcp_update() Cody P Schafer
2013-06-11 22:12 ` Cody P Schafer
2013-06-12 21:20 ` Andrew Morton
2013-06-12 21:20 ` Andrew Morton
2013-06-12 21:45 ` Cody P Schafer [this message]
2013-06-12 21:45 ` Cody P Schafer
2013-06-12 21:50 ` Cody P Schafer
2013-06-12 21:50 ` Cody P Schafer
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=51B8EC10.6070304@linux.vnet.ibm.com \
--to=cody@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.