lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <b0943d9e0608291406o423c2e7axb4131b928257c3da@mail.gmail.com>
Date:	Tue, 29 Aug 2006 22:06:49 +0100
From:	"Catalin Marinas" <catalin.marinas@...il.com>
To:	"Michal Piotrowski" <michal.k.k.piotrowski@...il.com>
Cc:	linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>
Subject: Re: [PATCH 2.6.18-rc4 00/10] Kernel memory leak detector 0.9

On 17/08/06, Catalin Marinas <catalin.marinas@...il.com> wrote:
> it looks like it was caused by commit
> fc818301a8a39fedd7f0a71f878f29130c72193d where free_block() now calls
> slab_destroy() with l3->list_lock held.
[...]
> It leaves me with the options of either implementing my own memory
> allocator based on pages (including a simple hash table instead of
> radix tree) or fix the locking in kmemleak so that memory allocations
> happen without memleak_lock held. The latter is a bit complicated as
> well since any slab allocation causes a re-entrance into kmemleak.

FYI, I couldn't fix the locking dependency issues without modifying
the radix-tree implementation since even if you preload the tree
outside the memleak lock, it still tries to allocate memory in
radix_tree_insert.

I'll instead use a hash table (together with hlist) where I can
control the memory allocations and make more use of RCU. In my few
initial tests, the memory search with hash tables is about the same
speed (if not slightly faster) as the radix-tree implementation.

I will post a new kmemleak version by the end of this week.

-- 
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ