linux-kernel - Re: [RFC PATCH 5/5] tracing/events: modify kmem print to new format

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:	Tue, 9 Jun 2009 09:08:05 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mel Gorman <mel@....ul.ie>
cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan.kim@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	Rik van Riel <riel@...hat.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Theodore Tso <tytso@....edu>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Zhaolei <zhaolei@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Jason Baron <jbaron@...hat.com>,
	Jiaying Zhang <jiayingz@...gle.com>
Subject: Re: [RFC PATCH 5/5] tracing/events: modify kmem print to new
 format


On Tue, 9 Jun 2009, Mel Gorman wrote:

> On Tue, Jun 09, 2009 at 09:12:42AM +0200, Peter Zijlstra wrote:
> > On Mon, 2009-06-08 at 21:45 -0400, Steven Rostedt wrote:
> > 
> > > +#define show_gfp_flags(end...)						\
> > > +	"0=GFP_NOWAIT,"							\
> > > +	"0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s," \
> > > +	"0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s," \
> > > +	"0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s,0x%lx=%s," \
> > > +	"0x%lx=%s,0x%lx=%s>" end ,					\
> > > +	(unsigned long)GFP_HIGHUSER_MOVABLE,	"GFP_HIGHUSER_MOVABLE", \
> > > +	(unsigned long)GFP_HIGHUSER,		"GFP_HIGHUSER",		\
> > > +	(unsigned long)GFP_USER,		"GFP_USER",		\
> > > +	(unsigned long)GFP_TEMPORARY,		"GFP_TEMPORARY",	\
> > > +	(unsigned long)GFP_KERNEL,		"GFP_KERNEL",		\
> > > +	(unsigned long)GFP_NOFS,		"GFP_NOFS",		\
> > > +	(unsigned long)GFP_ATOMIC,		"GFP_ATOMIC",		\
> > > +	(unsigned long)GFP_NOIO,		"GFP_NOIO",		\
> > > +	(unsigned long)__GFP_HIGH,		"GFP_HIGH",		\
> > > +	(unsigned long)__GFP_WAIT,		"GFP_WAIT",		\
> > > +	(unsigned long)__GFP_IO,		"GFP_IO",		\
> > > +	(unsigned long)__GFP_COLD,		"GFP_COLD",		\
> > > +	(unsigned long)__GFP_NOWARN,		"GFP_NOWARN",		\
> > > +	(unsigned long)__GFP_REPEAT,		"GFP_REPEAT",		\
> > > +	(unsigned long)__GFP_NOFAIL,		"GFP_NOFAIL",		\
> > > +	(unsigned long)__GFP_NORETRY,		"GFP_NORETRY",		\
> > > +	(unsigned long)__GFP_COMP,		"GFP_COMP",		\
> > > +	(unsigned long)__GFP_ZERO,		"GFP_ZERO",		\
> > > +	(unsigned long)__GFP_NOMEMALLOC,	"GFP_NOMEMALLOC",	\
> > > +	(unsigned long)__GFP_HARDWALL,		"GFP_HARDWALL",		\
> > > +	(unsigned long)__GFP_THISNODE,		"GFP_THISNODE",		\
> > > +	(unsigned long)__GFP_RECLAIMABLE,	"GFP_RECLAIMABLE",	\
> > > +	(unsigned long)__GFP_MOVABLE,		"GFP_MOVABLE"
> > 
> > Just curious, how unhappy does stuff become when we add a __GFP_ flag
> > and forget to extend this table?
> > 
> 
> If it's the same behaviour as what I was looking at yesterday, it prints
> the remaining flags it doesn't recognise as the number.
> 
> GFP_KERNEL|__GFP_DMA got outputted as |GFP_KERNEL|0x1|

Yep, that is what would happen here too.

Any comments on this approach? I'll go ahead and start fixing it up more 
(handling all the memory freeing on errors) and get it ready to push out.

-- Steve

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