Re: [PATCH v2] exit: perform randomness and pid work without tasklist_lock

[Mateusz Guzik <mjguzik@gmail.com>]

On Tue, Jan 28, 2025 at 7:30 PM Oleg Nesterov <oleg@redhat.com> wrote:
>
> (Add Eric).
>
>
> On 01/28, Mateusz Guzik wrote:
> >
> > Both add_device_randomness() and attach_pid()/detach_pid()
>
> So afaics this patch does 2 different things, and I do think this needs
> 2 separate patches. Can you split this change please?
>

no problem, will send a v3 provided there are no issues reported
concerning the pid stuff

maybe i'll add few more things pulled out to further justify the struct

> As for add_device_randomness(). I must have missed something, but I still can't
> understand why we can't simply shift add_device_randomness(p->sum_exec_runtime)
> to release_release_task() and avoid release_task_post->randomness.
>
> You said:
>
>         I wanted to keep the load where it was
>
> but why??? Again, I must have missed something, but to me this simply adds the
> unnecessary complications. Either way, ->sum_exec_runtime is not stable even if
> task-to-release != current, so what is the point?
>

Perhaps I should preface this is not a hill I'm going to die on. :->

This is the spot which is known to work and release_task does not
access the area otherwise. So for all I know someone will change it
later to be freeable, zeroed for "hardening" or some other crap and
the read moved to later will quietly break to always add the same
value. So by default I don't want to change aspect.

However, if you insist on the read to just moving, I'll be more than
happy to do that in v3.
-- 
Mateusz Guzik <mjguzik gmail.com>