Q: ptrace && ->last_siginfo

Roland McGrath roland at redhat.com
Mon Sep 14 09:05:10 UTC 2009


> What for? OK, I guess .si_code = exit_code is useful, and we should
> be compatible anyway.

This comment above ptrace_stop:

 * We always set current->last_siginfo while stopped here.
 * That makes it a way to test a stopped process for
 * being ptrace-stopped vs being job-control-stopped.

dates from the 2004 rewrite (original introduction of TASK_TRACED)
that made this ABI change.  I'd have to look up the mailing list
archives of the time to be sure, but my dim recollection is that this
was the preference of the GDB folks at the time.  Since then I have
probably advised people more than once that PTRACE_GETSIGINFO->EINVAL
is a check for job control stops.

> Now, how we can implement this? The obvious solution is to add
> "struct siginfo info" into ptrace_context, but this is a bit ugly.
> We need the pointer in ->context, yes. But can't we avoid adding
> 128 bytes to ptrace_context?

As you noted, in the non-signal cases it doesn't actually store any
extra useful information about the event.  So it's not always needed
at event time.

> Sure. This can break the test-case or stupid application which writes
> something to ->last_siginfo via ptrace_getsiginfo(), then reads the data
> back via ptrace_setsiginfo() and expects the "correct" results.

Hmm.  I don't think we care if reading it back with PTRACE_GETSIGINFO
is the only way to notice.  It looks quite clear in the vanilla kernel
that nothing else could be affected, since it's a siginfo_t local in
ptrace_notify that is just abandoned.

> Can we live with this?

At the moment it seems like we can.  
We should keep the subject in mind though.

> I'd really like to avoid 128 unneeded bytes in ->context. Perhaps you
> have other ideas?

Worst case we could kalloc something in the rare case of the
PTRACE_SETSIGINFO call that had new information to store.
For now we could punt it and do a WARN_ON_ONCE for the case
of a PTRACE_SETSIGINFO call in that situation (or perhaps only
for one that sets it to other than what the default dummy read
would yield).


Thanks,
Roland




More information about the utrace-devel mailing list