Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 28 Apr 2006 09:03:44 +0300 (EEST) | From | Pekka J Enberg <> | Subject | Re: 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/
| ![\](/images/icornerr.gif) |