From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752480AbdCDKIT (ORCPT ); Sat, 4 Mar 2017 05:08:19 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:39072 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752458AbdCDKIQ (ORCPT ); Sat, 4 Mar 2017 05:08:16 -0500 Message-Id: <20170304092717.762954142@infradead.org> User-Agent: quilt/0.63-1 Date: Sat, 04 Mar 2017 10:27:17 +0100 From: Peter Zijlstra To: tglx@linutronix.de Cc: mingo@kernel.org, juri.lelli@arm.com, rostedt@goodmis.org, xlpang@redhat.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com, jdesfossez@efficios.com, bristot@redhat.com, dvhart@infradead.org, peterz@infradead.org Subject: [PATCH -v5 00/14] the saga of FUTEX_UNLOCK_PI wobbles continues Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, Here be the 5th iteration of these patches; which strive to unlock the rt_mutex without holding hb->lock. In total this patch-set is very much like the previous one (including the 'late' fix) but it gets there in a slightly different -- and hopefully easier to understand -- route. The last 3 patches could be superfluous if we can proof that the -EAGAIN retry in futex_unlock_pi() isn't a problem for bounded execution (or are willing to accept it). In this case the patch-set ends up simpler than before. I sincerely hope this is the last of it; but please consider carefully, there be dragons here.