linux-kernel - Re: [PATCH v10 Golden] Unified trace buffer

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: <1222790072.24384.21.camel@twins>
Date:	Tue, 30 Sep 2008 17:54:32 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jonathan Corbet <corbet@....net>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	David Wilder <dwilder@...ibm.com>, hch@....de,
	Martin Bligh <mbligh@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCH v10 Golden] Unified trace buffer

On Tue, 2008-09-30 at 09:20 -0600, Jonathan Corbet wrote:
> On Tue, 30 Sep 2008 00:00:11 -0400 (EDT)
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > Ah, I believe the disk IO uses the page frame. That might be a bit more 
> > difficult to pass the data to disk and still keep information on the
> > page frame.
> 
> Perhaps I'm speaking out of turn, but I have to wonder: am I the only one
> who gets uncomfortable looking at these hacks to overload struct page?  It
> seems fragile as all hell; woe to he who tries to make a change to struct
> page someday and has to track all of this stuff down.
> 
> Are the savings gained by using struct page this way really worth the
> added complexity?

Its not that complex IMHO, the thing that is ugly are those struct page
overloads, what we could do is try and sanitize the regular struct page
and pull all these things in.

Because the only reason people are doing these overloads is because
struct page in mm_types.h is becomming an unreadable mess.

Trouble is, looking at it I see no easy way out,

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