On Tue, Jan 28, 2025 at 7:30 PM Oleg Nesterov <oleg@xxxxxxxxxx> 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>
