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]

Date:	Tue, 30 Sep 2008 19:49:12 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jonathan Corbet <corbet@....net>,
	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, "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 13:41 -0400, Steven Rostedt wrote:
> On Tue, 30 Sep 2008, Peter Zijlstra wrote:
> > > 
> > > Actually, looking at the code, there is no reason I need to keep this in 
> > > the frame buffer itself. I've also encapsulated the accesses to the 
> > > incrementing of the pointers so it would be trivial to try other 
> > > approaches.
> > > 
> > > The problem we had with the big array struct is that we can want large 
> > > buffers and to do that with pointers means we would need to either come up 
> > > with a large allocator or use vmap.
> > > 
> > > But I just realized that I could also just make a link list of page 
> > > pointers and do the exact same thing without having to worry about page 
> > > frames.  Again, the way I coded this up, it is quite trivial to replace 
> > > the handling of the pages with other schemes.
> > 
> > The list_head in the page frame should be available regardless of
> > splice() stuffs.
> 
> Regardless, there's more info we want to store for each page than the list 
> head.  Especially when we start converting this to lockless. I rather get 
> out of the overlaying of the page frames, its nice to save the space, but 
> really scares the hell out of me. I can just imagine this blowing up if we 
> redo the paging, and I dislike this transparent coupling between the 
> tracer buffer and the pages.

The problem with storing the page link information inside the page is
that it doesnt transfer to another address space, so if you do indeed
mmap these pages, then the link information is bogus.

Of course, in such a situation you could ignore these headers, but
somehow that doesn't sound too apealing.

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