On 17/08/06, Michal Piotrowski <[email protected]> wrote:
On 17/08/06, Catalin Marinas <[email protected]> wrote:
> On 13/08/06, Michal Piotrowski <[email protected]> wrote:
> > It's kmemleak 0.9 issue. I have tested kmemleak 0.8 on 2.6.18-rc1and
> > 2.6.18-rc2. I haven't seen this before.
>
> it looks like it was caused by commit
> fc818301a8a39fedd7f0a71f878f29130c72193d where free_block() now calls
> slab_destroy() with l3->list_lock held.
I'll revert this commit.
I'm not sure it's a good idea, it might have other implications in
slab.c. I better fix kmemleak (I think currently you could get a
deadlock only on SMP).
Please talk with Christoph Lameter, he is working on Modular Slab.
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/0951.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.2/0030.html
Maybe he can help with this problem.
I haven't looked at these patches in detail but they look like making
the slab allocator cleaner.
Anyway, I still need to revisit the locking in kmemleak and not rely
on future changes to slab.c. At the moment I think I can avoid any
kmemleak locks when allocating memory (by using radix_tree_preload
with the radix trees). If this still fails, I'll think about writing
my own, very simple, memory allocator and avoid the re-entrance
problem.
Thanks.
--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
