On Fri, 9 Sept 2022 at 14:47, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Added linux-api because you are changing the api. Thanks. > Several things. First you are messing with /proc/<pid>/stat which is > heavily used. You do add the value to the end of the list which is > good. You don't talk about how many userspace applications you have > tested to be certain that it is actually safe to add something to this > file, nor do you talk about measuring performance. Makes sense. Given this and Kees comment above, it seems like status instead is a better place. That should deal with the compatibility issue given it's a key-value pair file. Do you have the same performance concerns for that file as well? > This implementation seems very fragile. How long until you need the > full siginfo of the signal that caused the process to exit somewhere? For our use case probably never. I don't know if someone else will eventually need everything. > There are two ways to get this information with existing APIs. > - Catch the signal in the process and give it to someone. This would involve establishing a back-channel from the child process to init, which is not impossible but also not particularly architecturally nice. > - Debug the process and stop in PTRACE_EVENT_EXIT and read > the signal with PTRACE_PEEKSIGINFO. This will not work with the SELinux rules we want to enforce on Android. > I know people have wanted the full siginfo on exit before, but we have > not gotten there yet. That sounds like a much bigger change. How would that look? A new sys-call to get the siginfo from a zombie? A new wait API? Florian
