lkml.org 
[lkml]   [2013]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] slub: assign refcount for kmalloc_caches
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


\
 
 \ /
  Last update: 2013-01-11 09:41    [W:0.762 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site