> 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