> On Sep 20, 2024, at 11:44 AM, Oleg Nesterov <o...@redhat.com> wrote:
> 
> On 09/20, Anjali Kulkarni wrote:
>> 
>>> On Sep 20, 2024, at 4:00 AM, Oleg Nesterov <o...@redhat.com> 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.
> 

Reply via email to