Re: [PATCH net-next 1/2] connector/cn_proc: Handle threads for proc connector

[Anjali Kulkarni]

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