On Jan 15, 2005 10:22 +0100, Andreas Gruenbacher wrote:
> On Saturday 15 January 2005 23:01, Andi Kleen wrote:
> Those are just bugs from the time before there was kmem_cache_destroy. I
> checked the 2.6.11-rc1-mm1 tree: every kmem_cache_create in modules seems to
> destroyed properly except in
On Saturday 15 January 2005 23:01, Andi Kleen wrote:
> > Based on the comment it is understood that suddenly this pointer points
> > to userspace, because the module got unloaded.
> > I wonder why we can rely on the same address now the module got unloaded
> > - we may risk this virtual address is
On Sat, Jan 15, 2005 at 11:01:51PM +0100, Andi Kleen wrote:
> > Based on the comment it is understood that suddenly this pointer points
> > to userspace, because the module got unloaded.
> > I wonder why we can rely on the same address now the module got unloaded -
> > we may risk this virtual addr
On Sat, Jan 15, 2005 at 11:01:51PM +0100, Andi Kleen wrote:
> > Based on the comment it is understood that suddenly this pointer points
> > to userspace, because the module got unloaded.
> > I wonder why we can rely on the same address now the module got unloaded -
> > we may risk this virtual addr
> Based on the comment it is understood that suddenly this pointer points
> to userspace, because the module got unloaded.
> I wonder why we can rely on the same address now the module got unloaded -
> we may risk this virtual address is taken over by someone else?
The address is not user space; y
Hi Andi, lkml.
In slab.c around line 1450 the following code is present:
list_for_each(p, &cache_chain) {
kmem_cache_t *pc = list_entry(p, kmem_cache_t, next);
char tmp;
/* This happens when the module gets unloaded and doesn't
destroy its slab cache and noone e
6 matches
Mail list logo
