Messages in this thread | | | Date | Thu, 27 Apr 2006 15:22:53 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: possible bug in kmem_cache related code |
| |
On Thu, 27 Apr 2006, Pekka Enberg wrote:
> 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 > > 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?
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()?
- 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/
| |