> On Sep 20, 2024, at 11:44 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > On 09/20, Anjali Kulkarni wrote: >> >>> On Sep 20, 2024, at 4:00 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: >>> >>> 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 > > Well. I don't understand your use-case. Or any other use-case for drivers/connector/ > that I know nothing about. But this is irrelevant. > > The new PROC_CN_MCAST_NOTIFY functionality you propose should work regardless of Yes, agreed. > whether this task is ptraced or not. But it doesn't because the usage of ->exit_code > in your patch conflicts with the current usage of this field. > Ok, I see that ptrace_stop() seems to be using it in much the same way I want to use it - as a temporary place to store some values. Since in do_exit(), exit_code is overwritten, I didn’t think anyone was using it. Could I add a new field in the task_struct to store my value? (I don’t think there is any other unused/field I can use temporarily) Anjali > So, NACK, sorry. > > Oleg. >
