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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b0943d9e0612190136x16ed4ffes37f2c023bb168b17@mail.gmail.com>
Date:	Tue, 19 Dec 2006 09:36:13 +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:
>
> > >at freeing we only have to look up the tree belonging to object->cpu.
> >
> > At freeing, kmemleak only gets a pointer value which has to be looked
> > up in the hash table for the corresponding memleak_object. Only after
> > that, we can know memleak_object->cpu. That's why I think we only need
> > to have a global hash table. The hash table look-up can be RCU.
> > [...]
>
> hmm ... nasty. Would it be feasible to embedd the memleak info into the
> allocated object itself? That would remove quite some runtime overhead,
> besides eliminating the global hash.

I thought about this but would be more difficult for page allocations
and even impossible if we later want to track ioremap'ed regions (or
any other resource that has a unique id). The vmalloc'ed regions are
page aligned, though not sure there is any code that makes use of this
assumption. It also makes it too dependent on the allocator itself
(maybe not a big problem). Being less intrusive makes this easier to
maintain, especially if you want to use a different allocator.

Another option would be to store kmemleak info in the slab management
structures, vm_area (for vmalloc) or page structures but this breaks
the kmemleak functions for marking the false positives (which is done
outside the allocator).

Is there any scalability/performance impact of just
acquiring/releasing a lock or this is only affected by the contention
situations? If it's the latter, there can be a lock per hash-table
entry and drastically reduce the contention. The drawback is the
doubling of the hash table size, maybe with some impact on caches and
TLBs.

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