[lkml]   [2011]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE_ATTACH
On Friday 04 February 2011 15:48, Tejun Heo wrote:
> > But even this doesn't matter. We can not change ptrace API so that,
> > say, it does not reparent the tracee. Once we do this, we already
> > have the new API.
> I would argue that we can get by well enough by trimming and updating
> the curren ptrace API.

In the past Roland wasn't very enthusiastic about changes which
were fixing ptrace's bugs-turned-features.

If you want to do that, you need to convince him to change
his position a bit.

For example, PTRACE_DETACH requires tracee to be stopped to succeed.
If debugger tries to detach while the tracee is running, it will get
an error. This forces debugger to do stupid things like sending SIGSTOP,
then waiting for tracee to stop, then doing PTRACE_DETACH, then
sending SIGCONT. Of course, while this dance is performed,
any SIGSTOPs/SIGCONTs which may be sent to the tracee by other processes
are totally disrupted by this.

The natural (for me) fix is to make PTRACE_DETACH work even on running
tracee. It simply makes a lot of sense. Why on earth do we need tracee
to be stopped? There is no reason.

But this is a change in ptrace behavior, and therefore is not acceptable
for Roland.

Basically, we have slightly idea what are ptrace's development goals are.

From my POV, we want to have strace tool which is *completely*, 100%
transparent for traced process and its parent (sans decrease in speed).
No "vfork turns into fork under strace" (we had this sometime ago),
no missed or misinterpreted SIGSTOPs or SIGTRAPs. Real parent
should still see its child stopping on ^Z even if strace -p PID
attached itself to the child. Etc etc etc.

If this can only be achieved by slightly changing (basically, fixing)
ptrace API, I'd go for it.

In many cases, Roland won't.

He is the maintainer. If you want changes which break some aspects of
current behavior, even quirky ones, you need to convince him.

> I could be wrong (with pretty high probability) but I don't really see
> the pressing need for a completely new API. ptrace sure is ugly and
> quirky but it's something people are already used to.


 \ /
  Last update: 2011-02-13 22:27    [W:0.183 / U:3.756 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site