On Sep 20, 2024, at 4:00 AM, Oleg Nesterov oleg@redhat.com wrote:
On 09/19, Anjali Kulkarni wrote:
@@ -413,6 +416,10 @@ static void cn_proc_mcast_ctl(struct cn_msg *msg, if (msg->len == sizeof(*pinput)) { pinput = (struct proc_input *)msg->data; mc_op = pinput->mcast_op;
if (mc_op == PROC_CN_MCAST_NOTIFY) {
current->exit_code = pinput->uexit_code;
return;
...
--- a/kernel/exit.c +++ b/kernel/exit.c @@ -821,6 +821,7 @@ void __noreturn do_exit(long code) { struct task_struct *tsk = current; int group_dead;
__u32 uexit_code;
WARN_ON(irqs_disabled());
@@ -863,6 +864,8 @@ void __noreturn do_exit(long code) tty_audit_exit(); audit_free(tsk);
- uexit_code = tsk->exit_code;
I don't think you can use task_struct->exit_code. If this task is ptraced, it can be changed/cleared in, say, ptrace_stop() after PROC_CN_MCAST_NOTIFY.
Thank you, that’s a good point! However, the use case of ptrace, which I assume is for mostly debug and tracing, is exclusive of the use case I am using it for - for production and mostly scaling scenarios. That is, I assume ptrace calls can be done only to your own processes (except superuser), so the tracing process should understand and only do one(ptrace) or the other (request for a exit notification by using a system call) and not both? I could add a comment or something which describes this somewhere. Another point is - if an exit_code is modified, it will anyways be overwritten in the do_exit() call - so it’s not clear to me what the purpose of writing that field would be for ptrace_stop() or any other function…? Is there any other reason for ptrace_stop() to modify task_struct->exit_code?
Anjali
Oleg.