an appraisal

[Forsythe, Tory]

Dear Utrace-devel

Your site should be at the top of the major search engines.  
Want a free site analysis?   If interested, just reply to this 
email and we can give you a free appraisal with no strings.


Sincerely
Tory Forsythe
Turbo-Media





















utrace-devel@redhat.com
1/22/2010

Re: s390 user_enable_single_step() (Was: odd utrace testing results on s390x)

[Oleg Nesterov]

On 01/07, Roland McGrath wrote:

  I am confused as well. Yes, I thought about regs-psw.mask change too,
  but I don't understand why it helps..
 [...]
  But. Acoording to the testing I did (unless I did something wrong
  again) this patch doesn't make any difference in this particular
  case. 6580807da14c423f0d0a708108e6df6ebc8bc83d does.

 Those results are quite mysterious to me.
 I think we'll have to get Martin to sort it out definitively.

I did the testing again with 2.6.32-5.el6 + Martin's
c3311c13adc1021e986fef12609ceb395ffc5014
f8d5faf718c9ff2c04eb8484585d4963c4111cd7
patches.

the same test-case:

#include stdio.h
#include unistd.h
#include signal.h
#include sys/ptrace.h
#include sys/wait.h
#include assert.h

int main(void)
{
int pid, status;

if (!(pid = fork())) {
assert(ptrace(PTRACE_TRACEME) == 0);
kill(getpid(), SIGSTOP);

if (!fork())
return 43;

wait(status);
return WEXITSTATUS(status);
}


for (;;) {
assert(pid == wait(status));
if (WIFEXITED(status))
break;
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);
}

assert(WEXITSTATUS(status) == 43);
return 0;
}

with the simple debugging patch below I did

# perl -e 'syscall 172, 666, 0,0'; ./xxx
# perl -e 'syscall 172, 666, 0,1'; ./xxx
# perl -e 'syscall 172, 666, 1,0'; ./xxx
# perl -e 'syscall 172, 666, 1,1'; ./xxx

and dmesg reports:

XXX disable_step=0, clear_flag=0
XXX: xxx/1868 0
[... 799 times ...]
XXX disable_step=0, clear_flag=1
XXX: xxx/1905 0
[... 799 times ...]
XXX disable_step=1, clear_flag=0
XXX disable_step=1, clear_flag=1

Just in case, I did the testing with and without CONFIG_UTRACE,
result is the same.

IOW, copy_thread()-clear_tsk_thread_flag(TIF_SINGLE_STEP) doesn't
make any difference, copy_process()-user_disable_single_step() does.

Although I need to re-read Martin's explanations about psw magic,
perhaps this was already explained...

Oleg.

--- K/kernel/sys.c~ 2010-01-21 14:16:15.366639654 -0500
+++ K/kernel/sys.c  2010-01-21 14:30:35.131591879 -0500
@@ -1453,6 +1453,8 @@ SYSCALL_DEFINE1(umask, int, mask)
return mask;
 }
 
+int xxx_disable_step, xxx_clear_flag;
+
 SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
unsigned long, arg4, unsigned long, arg5)
 {
@@ -1466,6 +1468,13 @@ SYSCALL_DEFINE5(prctl, int, option, unsi
 
error = 0;
switch (option) {
+   case 666:
+   xxx_disable_step = arg2;
+   xxx_clear_flag = arg3;
+   printk(KERN_INFO XXX disable_step=%d, clear_flag=%d\n,
+   xxx_disable_step, xxx_clear_flag);
+   break;
+
case PR_SET_PDEATHSIG:
if (!valid_signal(arg2)) {
error = -EINVAL;
--- K/kernel/fork.c~2010-01-18 09:35:16.823811008 -0500
+++ K/kernel/fork.c 2010-01-21 14:29:39.131624971 -0500
@@ -964,6 +964,8 @@ static void posix_cpu_timers_init(struct
INIT_LIST_HEAD(tsk-cpu_timers[2]);
 }
 
+extern int xxx_disable_step;
+
 /*
  * This creates a new process as a copy of the old one,
  * but does not actually start it yet.
@@ -1207,7 +1209,8 @@ static struct task_struct *copy_process(
 * Syscall tracing and stepping should be turned off in the
 * child regardless of CLONE_PTRACE.
 */
-   user_disable_single_step(p);
+   if (xxx_disable_step)
+   user_disable_single_step(p);
clear_tsk_thread_flag(p, TIF_SYSCALL_TRACE);
 #ifdef TIF_SYSCALL_EMU
clear_tsk_thread_flag(p, TIF_SYSCALL_EMU);
--- K/arch/s390/kernel/process.c~   2010-01-21 14:32:38.541609793 -0500
+++ K/arch/s390/kernel/process.c2010-01-21 14:34:10.461584130 -0500
@@ -161,6 +161,8 @@ void release_thread(struct task_struct *
 {
 }
 
+extern int xxx_clear_flag;
+
 int copy_thread(unsigned long clone_flags, unsigned long new_stackp,
unsigned long unused,
struct task_struct *p, struct pt_regs *regs)
@@ -217,7 +219,8 @@ int copy_thread(unsigned long clone_flag
p-thread.mm_segment = get_fs();
/* Don't copy debug registers */
memset(p-thread.per_info, 0, sizeof(p-thread.per_info));
-   clear_tsk_thread_flag(p, TIF_SINGLE_STEP);
+   if (xxx_clear_flag)
+   clear_tsk_thread_flag(p, TIF_SINGLE_STEP);
/* Initialize per thread user and system timer values */
ti = 

Re: linux-next: add utrace tree

[Frank Ch. Eigler]

Hi -

On Thu, Jan 21, 2010 at 04:31:45PM -0800, Andrew Morton wrote:
 [...]
  Someone please sell this to us.
 Here's what Oleg said last time I asked this: [...]

I wonder if Roland/Oleg are being too modest in their current role as
ptrace maintainers.  Considering that *they* think of utrace as a
means toward proper refactoring of ptrace, how much further burden of
proof should they shoulder?  To what extent are other subsystem
maintainers required to sell reworkings of their areas, when there
appear to be no drawbacks and at least arguable benefits?

- FChE

Re: linux-next: add utrace tree

[Frank Ch. Eigler]

Hi -

On Thu, Jan 21, 2010 at 05:05:41PM -0800, Andrew Morton wrote:

 [...]  ptrace is a nasty, complex part of the kernel which has a
 long history of problems, but it's all been pretty quiet in there
 for the the past few years.  This leads one to expect that a
 rip-out-n-rewrite is a high-risk prospect.  So, quite reasonably,
 one looks for a good reason for taking such risk. [...]

To the extent the discussion is colored by risk avoidance, then the
answer to that would consist of code reviews, and of course a look at
the actual historical reliability of this code.  While some might
enjoy reminding us about the brief kerneloops incident in 2008, let's
keep in mind that versions of this code has been deployed in fedora
and rhel for several *years*, with millions of users.  It's not some
rickety experiment.

To the extent the discussion is colored by the new features enabled
from this refactoring, well, there is Oleg's list which may or may not
have mentioned enabling systemtap's user-space probing.  More details
can be furnished on demand.  Several of the use examples were
constructed in good faith upon request from the kernel community
asking for more and more.  But what's enough?  Who knows, really?


- FChE

Re: linux-next: add utrace tree

[Linus Torvalds]

On Thu, 21 Jan 2010, Andrew Morton wrote:
 
 ptrace is a nasty, complex part of the kernel which has a long history
 of problems, but it's all been pretty quiet in there for the the past few
 years.

More importantly, we're not ever going to get rid of it. 

Quite frankly, judging my all past history we have ever seen in kernel 
interfaces, new an non-portable interfaces simply are never used. The 
whole question whether they are nicer or not is entirely immaterial. 

I'm personally very dubious that there are any merits to utrace that 
outweigh the very clear disadvantages: just another layer that adds a new 
level of abstraction to the only interface that people actually _use_, 
namely ptrace.

But I haven't followed utrace. I doubt _anybody_ has, except for the 
utrace people themselves.

Linus

Re: linux-next: add utrace tree

[Linus Torvalds]

On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
 
 To the extent the discussion is colored by the new features enabled
 from this refactoring, well, there is Oleg's list which may or may not
 have mentioned enabling systemtap's user-space probing.

Let's face it, system tap isn't going to be merged, so why even bring it 
up? Every kernel developer I have _ever_ seen agrees that all the new 
tracing is a million times superior. I'm sure there are system tap people 
who disagree, but quite frankly, I don't see it being merged considering 
how little the system tap people ever did for the kernel.

So if things like system tap and security models that go behind the 
kernel by tying into utrace are the reasons for utrace, color me utterly 
uninterested. In fact, color me actively hostile. I think that's the worst 
possible situation that we'd ever be in as kernel people (namely exactly 
the do things in kernel space by hiding behind utrace without having 
kernel people involved)

Linus

Re: linux-next: add utrace tree

[Frank Ch. Eigler]

Hi -

On Thu, Jan 21, 2010 at 05:32:47PM -0800, Linus Torvalds wrote:
 [...]
  To the extent the discussion is colored by the new features enabled
  from this refactoring, well, there is Oleg's list which may or may not
  have mentioned enabling systemtap's user-space probing.
 
 Let's face it, system tap isn't going to be merged, so why even bring it 
 up?

It was certainly not meant to derail the discussion about the merits
of utrace as a useful cleanup API in its own right, but rather to be
an example of what kinds of things become straightforward in its
presence.  You may be aware of nascent efforts to bring the same
uprobes infrastructure to perf.

 Every kernel developer I have _ever_ seen agrees that all the new
 tracing is a million times superior. [...]

And that is fine.  We believe there is plenty of space in the problem
domain for different approaches.

 ... considering how little the system tap people ever did for the kernel.

Less passionate analysis would identify a long history of contribution
by the the greater affiliated team, including via merged code and by
and passing on requirements and experiences.  We have been trying to
share as much as you have been willing to take.  While systemtap's
current codebase may not (and need not) have a future inside the
kernel, chances are good that improvements in common infrastructure
will allow systemtap to shrink and change enough that the question
becomes moot.


- FChE

Re: linux-next: add utrace tree

[Linus Torvalds]

On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
 
 Less passionate analysis would identify a long history of contribution
 by the the greater affiliated team, including via merged code and by
 and passing on requirements and experiences.

The reason I'm so passionate is that I dislike the turn the discussion was 
taking, as if utrace was somehow _good_ because it allowed various other 
interfaces to hide behind it. And I'm not at all convinced that is true. 

And I really didn't want to single out system tap, I very much feel the 
same way abotu some seccomp-replacement security model that the kernel 
doesn't even need to know about thing.

So don't take the systemtap part to be the important part, it's the bigger 
issue of I'd much rather have explicit interfaces than have generic hooks 
that people can then use in any random way.

I realize that my argument is very anti-thetical to the normal CS teaching 
of general-purpose is good. I often feel that very specific code with 
very clearly defined (and limited) applicability is a good thing - I'd 
rather have just a very specific ptrace layer that does nothing but 
ptrace, than a generic plugin layer that can be layered under ptrace and 
other things.

In one case, you know exactly what the users are, and what the semantics 
are going to be. In the other, you don't. 

So I really want to see a very big and immediate upside from utrace. 
Because to me, the it's a generic layer with any application you want to 
throw at it is a _downside_.

Linus

Re: linux-next: add utrace tree

[Ananth N Mavinakayanahalli]

On Thu, Jan 21, 2010 at 05:28:42PM -0800, Linus Torvalds wrote:
 
 
 On Thu, 21 Jan 2010, Andrew Morton wrote:
  
  ptrace is a nasty, complex part of the kernel which has a long history
  of problems, but it's all been pretty quiet in there for the the past few
  years.
 
 More importantly, we're not ever going to get rid of it. 

FWIW, Oleg's implementation of ptrace over utrace is 100% compatible
with legacy ptrace; gdb testsuite indicates that
(http://lkml.org/lkml/2009/12/21/98).

Ananth

Fw: Re: linux-next: add utrace tree

[Srikar Dronamraju]

Hi Roland, Oleg,

Would it be a good idea to probably start looking at user space api for
utrace? By doing that we would get usecases that maintainers in LKML are
looking for and start looking at its usefulness.

Currently its probably a egg and chicken case where they look at what
end customers are getting that additional benefit from utrace and we are
looking at providing the user interface after the bits go in.

--
Thanks and Regards
Srikar
---BeginMessage---
On Fri, 22 Jan 2010 11:17:47 +1100
Stephen Rothwell s...@canb.auug.org.au wrote:

 Any thoughts?

I'm nearly a week behind again and am trying to avoid thinking.

I've had a (n old) version of utrace in -mm for ages and it didn't
break anything.

I still don't think I've seen a really compelling reason for merging
it.  At least, I wouldn't be able to explain why we did it.  But
presumably there _are_ such reasons, because it was a lot of development work.

Someone please sell this to us.

---End Message---

Re: [RFC] [PATCH 0/7] UBP, XOL and Uprobes [ Summary of Comments and actions to be taken ]

[Srikar Dronamraju]

Here is a summary of the Comments and actions that need to be taken for
the current uprobes patchset. Please let me know if I missed or
misunderstood any of your comments.  

1. Uprobes depends on trap signal.
Uprobes depends on trap signal rather than hooking to the global
die notifier. It was suggested that we hook to the global die notifier.

In the next version of patches, Uprobes will use the global die
notifier and look at the per-task count of the probes in use to
see if it has to be consumed.

However this would reduce the ability of uprobe handlers to
sleep. Since we are dealing with userspace, sleeping in handlers
would have been a good feature. We are looking at ways to get
around this limitation.


2. XOL vma vs Emulation vs Single Stepping Inline vs using Protection
Rings.
XOL VMA is an additional process address vma.  This is
opposition to add an additional vma without user actually
requesting for the same.

XOL vma and single stepping inline are the two architecture
independent implementations. While other implementations are
more architecture specific. Single stepping inline wouldnt go
well with multithreaded process.

Even though XOL vma has its own issues, we will go with it since
other implementations seem to have more complications.

we would look forward to implementing boosters later. 
Later on, if we come across another techniques with lesser
side-effects than the XOL vma, we would switch to using them.


3. Current Uprobes looks at process life times and not vma lifetimes. 
Also it needs threads to quiesce when inserting and removing
breakpoints.

Current uprobes was quiesing threads of a process before
insertion and deletion. This resulted in uprobes having to track
process lifetimes. An alternative method to track vma lifetimes
was suggested.

Next version would update the copy of the page and flip the
pagetables as suggested by Peter. Hence it would no more depend on
threads quiescing.

However this would need hooks in munmap/rmap so that uprobes can
remove breakpoints that are placed in that vma.

This would also mean removing the rcu_deference we were using.

4. Move the ftrace plugin to use trace events.

Since ftrace plugins are relegated to obsolescence, it was
suggested we use trace events which would have much wider scope.

Next version will use trace events.

5. rename UBP to user_bkpt

6. updating the authors for all files that are getting added.

I shall work towards v2 of uprobes and send across the patches at the
earliest.

--
Thanks and Regards
Srikar

Re: [RFC] [PATCH 0/7] UBP, XOL and Uprobes [ Summary of Comments and actions to be taken ]

[Ananth N Mavinakayanahalli]

On Fri, Jan 22, 2010 at 12:32:32PM +0530, Srikar Dronamraju wrote:
 Here is a summary of the Comments and actions that need to be taken for
 the current uprobes patchset. Please let me know if I missed or
 misunderstood any of your comments.  
 
 1. Uprobes depends on trap signal.
   Uprobes depends on trap signal rather than hooking to the global
 die notifier. It was suggested that we hook to the global die notifier.
 
   In the next version of patches, Uprobes will use the global die
   notifier and look at the per-task count of the probes in use to
   see if it has to be consumed.
 
   However this would reduce the ability of uprobe handlers to
   sleep. Since we are dealing with userspace, sleeping in handlers
   would have been a good feature. We are looking at ways to get
   around this limitation.

We could set a TIF_ flag in the notifier to indicate a breakpoint hit
and process it in task context before the task heads into userspace.

Ananth