linux-kernel - Re: + page-owner-tracking.patch added to -mm tree

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]

Date:	Sat, 4 Apr 2009 17:08:52 +0300
From:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Vegard Nossum <vegard.nossum@...il.com>,
	Mel Gorman <mel@....ul.ie>, Jason Baron <jbaron@...hat.com>,
	linux-kernel@...r.kernel.org, mm-commits@...r.kernel.org,
	alexn@....su.se, akpm@...ux-foundation.org, alexn@...ia.com,
	apw@...dowen.org, cl@...ux-foundation.org, haveblue@...ibm.com,
	kamezawa.hiroyu@...fujitu.com,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Steven Rostedt <rostedt@...dmis.org>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: + page-owner-tracking.patch added to -mm tree

On Fri, Apr 03, 2009 at 04:43:44PM +0200, Ingo Molnar wrote:
> 
> * Pekka Enberg <penberg@...helsinki.fi> wrote:
> 
> > Ingo Molnar wrote:
> >> * Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro> wrote:
> >>
> >>> One thing I'm not sure about this patch is whether it manages to  
> >>> record an allocation only once, i.e. does it log a single event  
> >>> when/if the slab allocator requests pages? Some time ago I sent a  
> >>> patch adding GFP_NOTRACE to gfp.h, but was rejected. Maybe this  
> >>> could be a way out of the mess.
> >>>
> >>> (GFP_NOTRACE would also allow us to log "backend" allocations easily 
> >>> and treat them separately, for the record, or simply filter them 
> >>> out.)
> >>
> >> makes a lot of sense IMO to annotate these via a GFP flag.
> >
> > Yup, make sense. I think I rejected the patch (did I?) because I 
> > wanted to fix the slub/slab mess differently but here it makes 
> > perfect sense.

Uh, I don't remember exactly, not sure who did it.

But to expand on the upside of doing it this way, we could expect to see
something like...

xxxxx	CPU0	GFP_KERNEL			kmalloc
xxxxx	CPU0	GFP_KERNEL | GFP_NOTRACE	__get_free_pages
xxxxx	CPU0	GFP_KERNEL | GFP_NOTRACE	kmalloc
xxxxx	CPU0	GFP_KERNEL			kmem_cache_alloc

So it's easy to see that allocations 2 and 3 are in fact part of the
fourth. It will get confused by IRQs, preemption and sleeping while
allocating, but we could use additional information (e.g. tracking
returned ptr's) to eliminate some/many such confusions in userspace.

> I'm wondering how much could be shared with the kmemcheck's 
> internal-allocation annotations. There's some overlap (although not 
> a full match) i suspect?
> 
> 	Ingo

I had already suggested this to Vegard some time ago. Basically,
kmemcheck should hook to the same tracepoints. As far as I remember,
kmemtrace gets more info out of the allocators, so this should suit
kmemcheck as well. Though this would incur additional overhead for the
latter due to the extra parameters being passed, but kmemcheck is slow
anyway.


	Eduard

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