From: Alexey Dobriyan <adobriyan@sw.ru>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
gregkh@suse.de, linux-kernel@vger.kernel.org
Subject: Re: 2.6.23-rc6-mm1: BUG kmalloc-16: Object padding overwritten (sysfs?)
Date: Fri, 21 Sep 2007 11:16:41 +0400 [thread overview]
Message-ID: <20070921071641.GA30924@localhost.sw.ru> (raw)
In-Reply-To: <Pine.LNX.4.64.0709201026520.8283@schroedinger.engr.sgi.com>
On Thu, Sep 20, 2007 at 10:36:13AM -0700, Christoph Lameter wrote:
> On Thu, 20 Sep 2007, Alexey Dobriyan wrote:
> > The winner is slub-avoid-touching-page-struct-when-freeing-to-per-cpu-slab.patch
> > Blind bisecting pointed to it and reverting the patch from full -mm makes
> > the problem go away
>
> Hmmm.. This means likely that the c->node is used somewhere for
> indexing.... Ahhh... If we count objects for sysfs output then c->node may
> be used to index into the statistics array. The offset from the poison
> also makes sense now since we increment values there.
>
> Does this patch fix the issue?
Yes, it does.
> SLUB: Fix slab object counting.
>
> We can only use the node value of the per cpu structure for counting if it
> is positive. A negative value indicates that the slab is not valid.
>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> ---
> mm/slub.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.23-rc6-mm1/mm/slub.c
> ===================================================================
> --- linux-2.6.23-rc6-mm1.orig/mm/slub.c 2007-09-20 10:31:04.000000000 -0700
> +++ linux-2.6.23-rc6-mm1/mm/slub.c 2007-09-20 10:32:19.000000000 -0700
> @@ -3412,12 +3412,16 @@ static unsigned long slab_objects(struct
>
> for_each_possible_cpu(cpu) {
> struct page *page;
> + int node;
> struct kmem_cache_cpu *c = get_cpu_slab(s, cpu);
>
> if (!c)
> continue;
>
> page = c->page;
> + node = c->node;
> + if (node < 0)
> + continue;
> if (page) {
> if (flags & SO_CPU) {
> int x = 0;
> @@ -3427,9 +3431,9 @@ static unsigned long slab_objects(struct
> else
> x = 1;
> total += x;
> - nodes[c->node] += x;
> + nodes[node] += x;
> }
> - per_cpu[c->node]++;
> + per_cpu[node]++;
> }
> }
>
next prev parent reply other threads:[~2007-09-21 7:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-19 12:39 2.6.23-rc6-mm1: BUG kmalloc-16: Object padding overwritten (sysfs?) Alexey Dobriyan
2007-09-19 12:59 ` Alexey Dobriyan
2007-09-19 19:39 ` Andrew Morton
2007-09-19 20:59 ` Christoph Lameter
2007-09-19 21:36 ` Christoph Lameter
2007-09-20 7:53 ` Alexey Dobriyan
2007-09-20 10:32 ` Alexey Dobriyan
2007-09-20 17:36 ` Christoph Lameter
2007-09-21 7:16 ` Alexey Dobriyan [this message]
2007-09-20 17:25 ` Christoph Lameter
2007-09-20 17:37 ` Christoph Lameter
2007-09-20 18:54 ` Eric W. Biederman
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=20070921071641.GA30924@localhost.sw.ru \
--to=adobriyan@sw.ru \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.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