On Fri, May 01, 2020 at 08:05:39PM -0700, Davidlohr Bueso wrote: > For both setpriority(2) and getpriority(2) there's really no need > to be taking the tasklist_lock at all - for which both share it > for the entirety of the syscall. The tasklist_lock does not protect > reading/writing the p->static_prio and task lookups are already rcu > safe, providing a stable pointer.
RCU-safe, as in, it will not crash.. However, without tasklist_lock the thread iterations (for PRIO_PGRP/PRIO_USER) now race against fork(). That is a user observable change in behaviour. Do we care about it? No idea, and your Changelog also doesn't provide clue.
