From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Paul Hargrove <phhargrove@lbl.gov>
Cc: Pekka Enberg <penberg@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter <cl@linux.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] slub: assign refcount for kmalloc_caches
Date: Fri, 11 Jan 2013 16:52:54 +0900 [thread overview]
Message-ID: <20130111075253.GB2346@lge.com> (raw)
In-Reply-To: <CAAvDA17eH0A_pr9siX7PTipe=Jd7WFZxR7mkUi6K0_djkH=FPA@mail.gmail.com>
On Thu, Jan 10, 2013 at 08:47:39PM -0800, Paul Hargrove wrote:
> I just had a look at patch-3.7.2-rc1, and this change doesn't appear to
> have made it in yet.
> Am I missing something?
>
> -Paul
I try to check it.
Ccing to Greg.
Hello, Pekka and Greg.
v3.8-rcX has already fixed by another stuff, but it is not simple change.
So I made a new patch and sent it.
How this kind of patch (only for stable v3.7) go into stable tree?
through Pekka's slab tree? or send it to Greg, directly?
I don't know how to submit this kind of patch to stable tree exactly.
Could anyone help me?
Thanks.
> On Tue, Dec 25, 2012 at 7:30 AM, JoonSoo Kim <js1304@gmail.com> wrote:
>
> > 2012/12/26 Joonsoo Kim <js1304@gmail.com>:
> > > commit cce89f4f6911286500cf7be0363f46c9b0a12ce0('Move kmem_cache
> > > refcounting to common code') moves some refcount manipulation code to
> > > common code. Unfortunately, it also removed refcount assignment for
> > > kmalloc_caches. So, kmalloc_caches's refcount is initially 0.
> > > This makes errornous situation.
> > >
> > > Paul Hargrove report that when he create a 8-byte kmem_cache and
> > > destory it, he encounter below message.
> > > 'Objects remaining in kmalloc-8 on kmem_cache_close()'
> > >
> > > 8-byte kmem_cache merge with 8-byte kmalloc cache and refcount is
> > > increased by one. So, resulting refcount is 1. When destory it, it hit
> > > refcount = 0, then kmem_cache_close() is executed and error message is
> > > printed.
> > >
> > > This patch assign initial refcount 1 to kmalloc_caches, so fix this
> > > errornous situtation.
> > >
> > > Cc: <stable@vger.kernel.org> # v3.7
> > > Cc: Christoph Lameter <cl@linux.com>
> > > Reported-by: Paul Hargrove <phhargrove@lbl.gov>
> > > Signed-off-by: Joonsoo Kim <js1304@gmail.com>
> > >
> > > diff --git a/mm/slub.c b/mm/slub.c
> > > index a0d6984..321afab 100644
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -3279,6 +3279,7 @@ static struct kmem_cache *__init
> > create_kmalloc_cache(const char *name,
> > > if (kmem_cache_open(s, flags))
> > > goto panic;
> > >
> > > + s->refcount = 1;
> > > list_add(&s->list, &slab_caches);
> > > return s;
> > >
> > > --
> > > 1.7.9.5
> > >
> >
> > I missed some explanation.
> > In v3.8-rc1, this problem is already solved.
> > See create_kmalloc_cache() in mm/slab_common.c.
> > So this patch is just for v3.7 stable.
> >
>
>
>
> --
> Paul H. Hargrove PHHargrove@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
--
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: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Paul Hargrove <phhargrove@lbl.gov>
Cc: Pekka Enberg <penberg@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter <cl@linux.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] slub: assign refcount for kmalloc_caches
Date: Fri, 11 Jan 2013 16:52:54 +0900 [thread overview]
Message-ID: <20130111075253.GB2346@lge.com> (raw)
In-Reply-To: <CAAvDA17eH0A_pr9siX7PTipe=Jd7WFZxR7mkUi6K0_djkH=FPA@mail.gmail.com>
On Thu, Jan 10, 2013 at 08:47:39PM -0800, Paul Hargrove wrote:
> I just had a look at patch-3.7.2-rc1, and this change doesn't appear to
> have made it in yet.
> Am I missing something?
>
> -Paul
I try to check it.
Ccing to Greg.
Hello, Pekka and Greg.
v3.8-rcX has already fixed by another stuff, but it is not simple change.
So I made a new patch and sent it.
How this kind of patch (only for stable v3.7) go into stable tree?
through Pekka's slab tree? or send it to Greg, directly?
I don't know how to submit this kind of patch to stable tree exactly.
Could anyone help me?
Thanks.
> On Tue, Dec 25, 2012 at 7:30 AM, JoonSoo Kim <js1304@gmail.com> wrote:
>
> > 2012/12/26 Joonsoo Kim <js1304@gmail.com>:
> > > commit cce89f4f6911286500cf7be0363f46c9b0a12ce0('Move kmem_cache
> > > refcounting to common code') moves some refcount manipulation code to
> > > common code. Unfortunately, it also removed refcount assignment for
> > > kmalloc_caches. So, kmalloc_caches's refcount is initially 0.
> > > This makes errornous situation.
> > >
> > > Paul Hargrove report that when he create a 8-byte kmem_cache and
> > > destory it, he encounter below message.
> > > 'Objects remaining in kmalloc-8 on kmem_cache_close()'
> > >
> > > 8-byte kmem_cache merge with 8-byte kmalloc cache and refcount is
> > > increased by one. So, resulting refcount is 1. When destory it, it hit
> > > refcount = 0, then kmem_cache_close() is executed and error message is
> > > printed.
> > >
> > > This patch assign initial refcount 1 to kmalloc_caches, so fix this
> > > errornous situtation.
> > >
> > > Cc: <stable@vger.kernel.org> # v3.7
> > > Cc: Christoph Lameter <cl@linux.com>
> > > Reported-by: Paul Hargrove <phhargrove@lbl.gov>
> > > Signed-off-by: Joonsoo Kim <js1304@gmail.com>
> > >
> > > diff --git a/mm/slub.c b/mm/slub.c
> > > index a0d6984..321afab 100644
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -3279,6 +3279,7 @@ static struct kmem_cache *__init
> > create_kmalloc_cache(const char *name,
> > > if (kmem_cache_open(s, flags))
> > > goto panic;
> > >
> > > + s->refcount = 1;
> > > list_add(&s->list, &slab_caches);
> > > return s;
> > >
> > > --
> > > 1.7.9.5
> > >
> >
> > I missed some explanation.
> > In v3.8-rc1, this problem is already solved.
> > See create_kmalloc_cache() in mm/slab_common.c.
> > So this patch is just for v3.7 stable.
> >
>
>
>
> --
> Paul H. Hargrove PHHargrove@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
next prev parent reply other threads:[~2013-01-11 7:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-25 0:55 BUG: slub creates kmalloc slabs with refcount=0 Paul Hargrove
2012-12-25 1:18 ` Paul Hargrove
2012-12-25 15:24 ` [PATCH] slub: assign refcount for kmalloc_caches Joonsoo Kim
2012-12-25 15:24 ` Joonsoo Kim
2012-12-25 15:30 ` JoonSoo Kim
2012-12-25 15:30 ` JoonSoo Kim
2013-01-11 4:47 ` Paul Hargrove
2013-01-11 7:52 ` Joonsoo Kim [this message]
2013-01-11 7:52 ` Joonsoo Kim
2013-01-14 19:23 ` Greg Kroah-Hartman
2013-01-14 19:23 ` Greg Kroah-Hartman
2013-01-25 3:32 ` CAI Qian
2013-01-25 3:32 ` CAI Qian
2013-01-29 6:07 ` Joonsoo Kim
2013-01-29 6:07 ` Joonsoo Kim
2012-12-27 16:06 ` Christoph Lameter
2012-12-27 16:06 ` Christoph Lameter
2012-12-25 15:32 ` BUG: slub creates kmalloc slabs with refcount=0 JoonSoo Kim
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=20130111075253.GB2346@lge.com \
--to=iamjoonsoo.kim@lge.com \
--cc=cl@linux.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=phhargrove@lbl.gov \
/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.