linux-kernel - Re: linux-next: add utrace 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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100122111747.3c224dfd.sfr@canb.auug.org.au>
Date:	Fri, 22 Jan 2010 11:17:47 +1100
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Peter Zijlstra <peterz@...radead.org>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>, linux-next@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus <torvalds@...ux-foundation.org>
Subject: Re: linux-next: add utrace tree

Hi Ingo, Andrew,

Any thoughts?

On Thu, 21 Jan 2010 01:38:22 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> On Wed, 20 Jan 2010 08:29:25 +0100 Ingo Molnar <mingo@...e.hu> wrote:
> >
> > 
> > * Ingo Molnar <mingo@...e.hu> wrote:
> > 
> > > 
> > > * Ananth N Mavinakayanahalli <ananth@...ibm.com> wrote:
> > > 
> > > > On Wed, Jan 20, 2010 at 06:49:50AM +0100, Ingo Molnar wrote:
> > > > 
> > > > Ingo,
> > > > 
> > > > > Note, i'm not yet convinced that this (and the rest: uprobes and systemtap, 
> > > > > etc.) can go uptream in its present form.
> > > > 
> > > > Agreed, uprobes is still not upstream ready -- it was an RFC. We are
> > > > working through the comments there to get it ready for merger.
> > > > 
> > > > > IMHO the far more important thing to address beyond formalities and workflow 
> > > > > cleanliness are the (many) technical observations and objections offered by 
> > > > > Peter Zijstra on lkml. Not just the git history but also the abstractions and 
> > > > > concepts are messy and should be reworked IMO, and also good and working perf 
> > > > > events integration should be achieved, etc.
> > > > 
> > > > I think Oleg addressed most of Peter's concerns on utrace when the 
> > > > ptrace/utrace patchset was reposted.
> > > 
> > > Peter is Cc:-ed and he might want to chime in.
> > > 
> > > > Perf integration with uprobes will be done and discussions have started with 
> > > > Masami and Frederic. There are a couple of fundamental technical aspects 
> > > > (XOL vma vs. emulation; breakpoint insertion through CoW and not through 
> > > > quiesce) that need resolution.
> > > > 
> > > > > The fact that there's a well established upstream workflow for instrumentation 
> > > > > patches, which is being routed around by the utrace/uprobes/systemtap code 
> > > > > here is not a good sign in terms of reaching a good upstream solution. Lets 
> > > > > hope it works out well though.
> > > > 
> > > > Agreed.
> > > > 
> > > > On the other hand, having ptrace/utrace in the -next tree will give it a
> > > > lot more testing, while any outstanding technical issues are being addressed.
> > > 
> > > Including experimental code that is RFC and which is not certain to go 
> > > upstream is certainly not the purpose of linux-next though.
> > > 
> > > It will cause conflicts with various other trees and increases the overhead 
> > > all around. It also causes us to trust linux-next bugreports less - as it's 
> > > not the 'next Linux' anymore. Also, there's virtually no high-level 
> > > technical review done in linux-next: the trees are implicitly trusted 
> > > (because they are pushed by maintainers), bugs and conflicts are reported 
> > > but otherwise it's a neutral tree that includes pretty much any commit 
> > > indiscriminately.
> > > 
> > > If you need review and testing there's a number of trees you can get 
> > > inclusion into.
> > 
> > Btw., the utrace code has lived in -mm for quite some time - that's an 
> > excellent route as Andrew does thorough review and testing.
> > 
> > If Andrew agrees with this particular tree as-is and wants these bits to live 
> > in linux-next and have it in -mm that way then that's a fair approach 
> > obviously and i have no objections ...
> 
> So, what is it to be?  In or out?
> 
> Frank, please be clear as to which branch you want included (master or
> utrace-ptrace).  Also note that neither of those branches matches what
> was posted in the sense that they both have lots of history and merges
> not represented in the patches.  (I assume that they do produce the same
> final source tree, though).
> 
> > The point is to have at least one relevant maintainer request and track it and 
> > then supervise the completion of it (which includes the resolution of all 
> > outstanding objections) and then push it to Linus.
> 
> If we do include it, it is still possible for people to decide (when the
> next merge window opens) that it is still not ready.  It adds a bit of
> maybe unneeded complication to linux-next, but we had the same problem in
> this merge window and we have all survived.  :-)
> 
> In the end, Linus is the final arbitrator of course.

-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au
http://www.canb.auug.org.au/~sfr/

Content of type "application/pgp-signature" skipped