linux-kernel - Re: [RFC,PATCH 0/14] utrace/ptrace

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:	Fri, 27 Nov 2009 09:04:39 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Ananth Mavinakayanahalli <ananth@...ibm.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org, utrace-devel@...hat.com
Subject: Re: [RFC,PATCH 0/14] utrace/ptrace

On Thu, Nov 26, 2009 at 01:24:41PM +0100, Ingo Molnar wrote:
> FYI, the merge window has not opened yet, so it cannot close in a few 
> days.

subsystems merged window, not Linus'.

> 
> > [...] and thus not getting any of the broad -next test coverage is a 
> > pretty bad idea.  In the end it will be the maintainers ruling but 
> > that doesn't make it a good idea from the engineering point of view.
> 
> FYI, it's been in -mm, that's where it's maintained.

None of the recent mm snapshots has anything utrace related in there,
just a few ptrace patches from Oleg (which are in this series but a very
small part of it) and certainly not all this new code that is pretty
recent (take a look at the utrace list for the development).

> Yes. Which is a further argument to not do it like that but to do one 
> arch at a time. Trying to do too much at once is bad engineering.

I'm not sure why you're trying to pick fights here, but no one has said
about doing it all in once.  The point I'm trying to make is that it's
pretty bad to keep parallel ptrace implementations, and we should settle
on one.  A pre-requisite of using the new once genericly is to have the
architecture ptrace code updated.  I think arm and mips are the two
only relevant ones still missing, so updating them and killing the other
ones is easy.

If you think keeping the two ptrace implementations is fine argue for
that directly, but please stick to the technical points instead of just
fighting for fightings sake.
--
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/