lkml.org 
[lkml]   [2007]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 1/3] SLUB: slab_ops instead of constructors / destructors
On 5/7/07, Bert Wesarg <wesarg@informatik.uni-halle.de> wrote:
> clameter@sgi.com wrote:
> > + if (ctor || dtor) {
> > + so = kzalloc(sizeof(struct slab_ops), GFP_KERNEL);
> > + so->ctor = ctor;
> > + so->dtor = dtor;
> > + }
> > + return __kmem_cache_create(s, size, align, flags, so);
> Is this a memory leak?

Yes, but see:

On 5/5/07, clameter@sgi.com <clameter@sgi.com> wrote:
> If constructor or destructor are specified then we will allocate a slab_ops
> structure and populate it with the values specified. Note that this will
> cause a memory leak if the slab is disposed of later. If you need disposable
> slabs then the new API must be used.

BTW:

> > + if (ctor || dtor) {
> > + so = kzalloc(sizeof(struct slab_ops), GFP_KERNEL);
> > + so->ctor = ctor;

It's also a potential oops, actually. kzalloc's return must be checked.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-05-06 21:49    [W:0.060 / U:19.892 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site