linux-kernel - Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b0943d9e0612180228w142a7375obf33a0f42d1982ae@mail.gmail.com>
Date:	Mon, 18 Dec 2006 10:28:43 +0000
From:	"Catalin Marinas" <catalin.marinas@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.20-rc1 00/10] Kernel memory leak detector 0.13

On 18/12/06, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Catalin Marinas <catalin.marinas@...il.com> wrote:
> > I could also use a simple allocator based on alloc_pages since
> > kmemleak doesn't track pages. [...]
>
> actually, i'm quite sure we want to track pages later on too, any reason
> why kmemleak shouldnt cover them?

It could track them but I'm not sure how efficient it would be since
you have different ways to get the page addresses like pfn, struct
page. The pfn would actually introduce a lot of false negatives.

This needs some investigation and it can probably be done but I'll
first focus on the slab allocator.

> > [...] It could be so simple that it would never need to free any
> > pages, just grow the size as required and reuse the freed memleak
> > objects from a list.
>
> sounds good to me. Please make it a per-CPU pool.

Isn't there a risk for the pools to become imbalanced? A lot of
allocations would initially happen on the first CPU.

> [...] (Add a memleak_object->cpu pointer so that freeing can be
> done on any other CPU as well.)

We could add the freed objects to the CPU pool where they were freed
and not use a memleak_object->cpu pointer.

> We'll have to fix the
> locking too, to be per-CPU - memleak_lock is quite a scalability problem
> right now.

The memleak_lock is indeed too coarse (but it was easier to track the
locking dependencies). With a new allocator, however, I could do a
finer grain locking. It probably still needs a (rw)lock for the hash
table. Having per-CPU hash tables is inefficient as we would have to
look up all the tables at every freeing or scanning for the
corresponding memleak_object.

There is a global object_list as well covered by memleak_lock (only
for insertions/deletions as traversing is RCU). Since modifications to
this list happen at the same time with the hash table modifications,
the memleak_lock is held anyway so we probably don't need to do
per-CPU object lists (they would also need some locking if freeing
would happen on a different CPU). List insertion/deletion is very
small compared to the hash-table look-up and it wouldn't introduce a
scalability problem.

-- 
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/