This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: utrace-based uprobes


> On Thu, 2007-03-15 at 17:21 -0700, Jim Keniston wrote:
> > o As of now, uprobes aren't inherited across fork()s.
> 
> Is there a special reason for this? It looks like you currently do extra
> work in case of a fork() to remove the breakpoints, which most likely
> will be cleared anyway as soon as the thread does an exec().

It should probably be selectable in some fashion.  Either way the thing
managing the probes is going to have to notice forks, whether to
utrace_attach to the child or to remove breakpoints from the child's memory
copy.

> Is this a requirement? I suppose modifying code while another thread can
> execute that code path is never safe. But do you have to suspend all
> threads? A suggestion would be to mark the code page as not executable
> so any thread that accesses that code path gets trapped till the code
> has been adjusted.

Without more infrastructure we don't yet have (cf "shangri-la" ;-), there is
no adequate means available to do that correctly and easily.

The SMP safety of modifying instruction memory surely varies by machine.
On x86, I think it may well be safe for a one-byte write at the beginning
of an instruction (as the breakpoint instruction is).  On RISC machines, I
would think an aligned word write of a whole instruction might be OK.
AFAICT kprobes doesn't do anything special about other CPUs vs arch_arm_kprobe.

> One problem that I recently encountered is that the process might have
> SIGTRAP masked or you might insert and then hit a breakpoint while a
> SIGTRAP handler is running in the user process [...]

This is one of several problems with signals induced by tracing activities.
In future, utrace will provide non-signal events to track induced machine
events like these, which will not have these problems.

> > +instruction.  If the process is not already stopped, Utrace sends it
> > +a SIGSTOP.  If the process is running an interruptible system call,
> > +this may cause the system call to finish early or fail with EINTR.
> 
> Is this a limitation of utrace at the moment? Or will it be possible in
> the future for utrace to "quiesce" a process without a "user visible"
> SIGSTOP signal?

Either Jim was speaking imprecisely, or he was mistaken.  There is no
SIGSTOP or other signal per se involved.  There is the signal-like effect
on a system call in progress, of possible EINTR or other anomalies, the
same side effects as any handled signal, stop signal + SIGCONT, or
ptrace-tracked signal (i.e. SIG_IGN or default-ignored signals not
short-circuited at generation).  This is the user-visible effect, which is
indeed undesireable.  Future utrace work will include "soft quiesce",
meaning a way to prevent a thread from returning to user mode, but without
interfering with a system call already in progress.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]