On 01/28, Mateusz Guzik wrote: > > On Tue, Jan 28, 2025 at 7:30 PM Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > > no problem, will send a v3 provided there are no issues reported > concerning the pid stuff Great, thanks. BTW, I didn't look at the pid stuff yet, I _feel_ that this can be simplified too, but I am already sleeping, most probably I am wrong. > > 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" sum_exec_runtime can't be freed/zeroed/etc in any case. Again, please note that task-to-release can still be running, especially if it is current. > always add the same value. I don't think that "add the same value" does matter at all in this case, but please correct me. > 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. Thanks, see above ;) Oleg.
