utrace/ptrace
in [Kernel]
|
Prev: [PATCH] NOMMU: use copy_*_user_page() in access_process_vm()
Next: [PATCH] spi: Allow using spi_bitbang_setup() with custom txrx_bufs()
From: Ananth N Mavinakayanahalli on 26 Nov 2009 03:00 On Wed, Nov 25, 2009 at 04:40:52PM +0100, Oleg Nesterov wrote: > On 11/25, Ananth N Mavinakayanahalli wrote: > > > > I ran the ptrace-tests testsuite [1] on powerpc on the vanilla ptrace > > and then with ptrace/utrace. The results for ptrace/utrace look better > > :-) > > Great! thanks a lot Ananth for doing this. > > ptrace-utrace still fails 2 tests, > > > FAIL: syscall-reset > > I'll take a look later. Since unpatched kernel fails this test too > I am not going to worry right now. I think this is ppc specific, x86 > passes this test. > > > step-fork: step-fork.c:56: handler_fail: Assertion `0' failed. > > /bin/sh: line 5: 24803 Aborted ${dir}$tst > > FAIL: step-fork > > This is expected. Should be fixed by > > ptrace-copy_process-should-disable-stepping.patch > > in -mm tree. (I am attaching this patch below just in case) > I din't mention this patch in this series because this bug > is "ortogonal" to utrace/ptrace. Oleg, The patch doesn't seem to fix the issue on powerpc: step-fork: step-fork.c:56: handler_fail: Assertion `0' failed. /bin/sh: line 5: 17325 Aborted ${dir}$tst FAIL: step-fork Ananth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 26 Nov 2009 04:20 * Christoph Hellwig <hch(a)infradead.org> wrote: > [...] Given that's it's pretty much too later for the 2.6.33 cycle > anyway I'd suggest you make sure the remaining two major architectures > (arm and mips) get converted, and if the remaining minor architectures > don't manage to get their homework done they're left without ptrace. I suspect the opinion of the ptrace maintainers matters heavily whether it's appropriate for v2.6.33. You are not going to maintain this, they are. Regarding porting it to even more architectures - that's pretty much the worst idea possible. It increases maintenance and testing overhead by exploding the test matrix, while giving little to end result. Plus the worst effect of it is that it becomes even more intrusive and even harder (and riskier) to merge. So dont do that. The best strategy is to concentrate on just one or two well-tested architectures, and then grow to other architectures gradually. Like we've done it for basically all big kernel features in the past 10 years (that had non-trivial arch dependencies), with no exception that i can remember. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 26 Nov 2009 05:50 On Thu, Nov 26, 2009 at 10:10:52AM +0100, Ingo Molnar wrote: > > [...] Given that's it's pretty much too later for the 2.6.33 cycle > > anyway I'd suggest you make sure the remaining two major architectures > > (arm and mips) get converted, and if the remaining minor architectures > > don't manage to get their homework done they're left without ptrace. > > I suspect the opinion of the ptrace maintainers matters heavily whether > it's appropriate for v2.6.33. You are not going to maintain this, they > are. I am whoever like many others going to use it. And throwing in new code a few days before the merge window closes 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. > Regarding porting it to even more architectures - that's pretty much the > worst idea possible. It increases maintenance and testing overhead by > exploding the test matrix, while giving little to end result. Plus the > worst effect of it is that it becomes even more intrusive and even > harder (and riskier) to merge. But it doesn't. Take a look at what these patches actually do, they basically introduce a new utrace layer, and (conditionally) rewrite ptrace to use it. The arch support isn't actually part of these patches directly but rather the cleanup of the underlying arch ptrace code to use regsets, tracehooks and co so that the new ptrace code can use. What the patches in the current form do is to introduce two different ptrace implementations, with one used on the architectures getting most testing and another secondary one for left over embedded or dead architectures with horrible results. So removing the old one is much better. The arm ptrace rewrite has already been posted by Roland, btw including some feedback from Russell, but nothing really happened to it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 26 Nov 2009 07:30 * Christoph Hellwig <hch(a)infradead.org> wrote: > On Thu, Nov 26, 2009 at 10:10:52AM +0100, Ingo Molnar wrote: > > > [...] Given that's it's pretty much too later for the 2.6.33 cycle > > > anyway I'd suggest you make sure the remaining two major architectures > > > (arm and mips) get converted, and if the remaining minor architectures > > > don't manage to get their homework done they're left without ptrace. > > > > I suspect the opinion of the ptrace maintainers matters heavily whether > > it's appropriate for v2.6.33. You are not going to maintain this, they > > are. > > I am whoever like many others going to use it. And throwing in new > code a few days before the merge window closes [...] FYI, the merge window has not opened yet, so it cannot close in a few days. > [...] 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. > > Regarding porting it to even more architectures - that's pretty much > > the worst idea possible. It increases maintenance and testing > > overhead by exploding the test matrix, while giving little to end > > result. Plus the worst effect of it is that it becomes even more > > intrusive and even harder (and riskier) to merge. > > But it doesn't. Take a look at what these patches actually do, they > basically introduce a new utrace layer, and (conditionally) rewrite > ptrace to use it. The arch support isn't actually part of these > patches directly but rather the cleanup of the underlying arch ptrace > code to use regsets, tracehooks and co so that the new ptrace code can > use. ( I am aware of its design, i merged the original tracehook patches for x86. ) > What the patches in the current form do is to introduce two different > ptrace implementations, with one used on the architectures getting > most testing and another secondary one for left over embedded or dead > architectures with horrible results. So removing the old one is much > better. The arm ptrace rewrite has already been posted by Roland, btw > including some feedback from Russell, but nothing really happened to > it. 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. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 26 Nov 2009 08:00
On Thu, 2009-11-26 at 12:37 +0530, Srikar Dronamraju wrote: > Hi Christoph, > > > > > The other thing is that this patchset really doesn't quite justify > > utrace. It's growing a lot more code without actually growing any > > useful functionality. What about all those other utrace killer > > features that have been promised for a long time? > > > > We are working on in-kernel gdbstub which was one of the features that > you had asked for. gdbstub does pass unit tests; but we are looking at > some way to hack the GDB testsuite to run its regression tests. Once we > are able to run the GDB testsuite and utrace is part of some upstream > tree, we plan to post these patches to LKML for comments. gdbstub uses > utrace and uprobes underneath. Uprobes was rewritten to remove issues > that LKML developers had opposed. Uprobes also has its own ftrace plugin > to use uprobes. > > Currently in-kernel gdbstub is hosted by Frank Ch. Eigler over here: > git://web.elastic.org/~fche/utrace-ext.git > branch name utrace-gdbstub-uprobes If its anywhere near functioning it would have made sense to send it out as an RFC patch-set right along with the utrace one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |