On Tue, Mar 09, 2021 at 11:06:03AM +0800, Zheng Yejian wrote: > From: Peter Zijlstra <[email protected]> > > Currently futex-pi relies on hb->lock to serialize everything. But hb->lock > creates another set of problems, especially priority inversions on RT where > hb->lock becomes a rt_mutex itself. > > The rt_mutex::wait_lock is the most obvious protection for keeping the > futex user space value and the kernel internal pi_state in sync. > > Rework and document the locking so rt_mutex::wait_lock is held accross all > operations which modify the user space value and the pi state. > > This allows to invoke rt_mutex_unlock() (including deboost) without holding > hb->lock as a next step. > > Nothing yet relies on the new locking rules. > > Signed-off-by: Peter Zijlstra (Intel) <[email protected]> > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Cc: [email protected] > Link: http://lkml.kernel.org/r/[email protected] > Signed-off-by: Thomas Gleixner <[email protected]> > [Lee: Back-ported in support of a previous futex back-port attempt] > Signed-off-by: Lee Jones <[email protected]> > Signed-off-by: Greg Kroah-Hartman <[email protected]> > Signed-off-by: Zheng Yejian <[email protected]> > --- > kernel/futex.c | 138 +++++++++++++++++++++++++++++++++++++++---------- > 1 file changed, 112 insertions(+), 26 deletions(-)
What is the git commit id of this patch in Linus's tree? thanks, greg k-h
