lkml.org 
[lkml]   [2006]   [Apr]   [28]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 28 Apr 2006 09:03:44 +0300 (EEST)
FromPekka J Enberg <>
SubjectRe: possible bug in kmem_cache related code
On 4/27/06, Or Gerlitz <ogerlitz@voltaire.com> wrote:
> > > With 2.6.17-rc3 I'm running into something which seems as a bug related
> > > to kmem_cache. Doing some allocations/deallocations from a kmem_cache and
> > > later attempting to destroy it yields the following message and trace

On Thu, 27 Apr 2006, Pekka Enberg wrote:
> > Tested on 2.6.16.7 and works ok. Christoph, could this be related to
> > the cache draining patches that went in 2.6.17-rc1?

On Thu, 27 Apr 2006, Christoph Lameter wrote:
> What happened to that part of the slab allocator? Looks completely  
> changed to when I saw it the last time?
> 
> This directly fails in kmem_cache_destroy?
> 
> So it tries to free all the slab entries from the free list and then 
> returns 1 or 2 if there are entries left on the partial and full 
> list? So the bug happens if cache entries are left.
> 
> Guess the reason for this failure is then that not all cache entries have 
> been freed before calling kmem_cache_destroy()?

Yes, but if you look at Or's test case, there's no obvious reason why 
that's happening. I'll see if I can reproduce the problem with 2.6.17-rc3.

					Pekka
-
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: 2006-04-28 08:06    [from the cache]
©2003-2008