> On Sep 20, 2024, at 4:00 AM, Oleg Nesterov <o...@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.
>
