Thread (2 messages) 2 messages, 2 authors, 2022-09-09

Re: [PATCH RESEND] Add sicode to /proc/<PID>/stat.

flat view

From: Florian Mayer <hidden>
Date: 2022-09-09 23:05:53
Also in: linux-doc, linux-fsdevel, lkml

On Fri, 9 Sept 2022 at 14:47, Eric W. Biederman [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help