Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp585234img; Fri, 22 Mar 2019 04:34:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqy11V3Ym/FWQhzrinp2pJ55I2LyXAFjDYS1KIwgTPvvu9CwjRlorBquiW61FHzpFpoH0RWt X-Received: by 2002:a65:624c:: with SMTP id q12mr8183702pgv.75.1553254469380; Fri, 22 Mar 2019 04:34:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553254469; cv=none; d=google.com; s=arc-20160816; b=wgm6SZBXLAhL+/P5ddxxRZvWnEkkKTVqavH/psVwtvpyv286Mi8SgKs0u/slN1hrwo MROc3AmfZ3OoEqCL6DsNyJpLqRra2XvKxn+/5Eyk0uMSK4XPxk+LRD/O+/iyrhmeHCkf OFxR2Mf8UqQdte67RUX7fJ3w41rEG1Hgt9+d6Xn3vFK7I0i+ReCvP3202P4pQEK0NZSX I/zIBo5LrIk9KPA3NJTQAK/czStQu8Lt3KYAklNZxa1fAmWf0sZosjqeK82pS6bQ5ErQ TiBczPOufhQ38R3M9V++Lu35cK8Z6MSyOUQ03bfkzJCxy+C4rBivX/fegp9WKFhlsF1p oTcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=a2es+HwT24ygkF74xBIt7QIpdaTsBq+PebPcIvM5Dn4=; b=I7ITSc+KeFic6V2ER/NkXBpuwna2Ir6+ro1M82okiwh4yHa8tRfFO41zd5mOYpwS9p 5iFpmECRZGvjP+F9sbPdLr9omCE7aKnuQ3wqghsr9Zdq/zcXaC62BmW53jtcnITtneK9 Iox9hykqGiXqcdDWWrjrMKE+8UPX21SwVwq2bkGroaUbMDgamPLEGkiuYCz0ZNC203Mp 9bcV1fTZVgEy1ZL6zNcSBAtUxBGr2ipdZooiBCtDqEdAAioYA3N0OokarYFI9pSCLqpp 67gvrlToaC0Kn/7eu18MP6D4AkiP3aZK6SLf3xJFEDNg9GRTPQFznyd3JFNWOwZMehdU Kxpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Kc41BHXq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b38si5657978pgb.107.2019.03.22.04.34.11; Fri, 22 Mar 2019 04:34:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Kc41BHXq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730252AbfCVLdT (ORCPT + 99 others); Fri, 22 Mar 2019 07:33:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:33656 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730244AbfCVLdQ (ORCPT ); Fri, 22 Mar 2019 07:33:16 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1A8DA20449; Fri, 22 Mar 2019 11:33:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553254394; bh=zR8UhD4zllPAfhgMrB7JOR4kEWth0nY1OHjiAn9T1ps=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kc41BHXqK0pDmV/fA3TPvIwPlTu1YPdEioYBiASGCwR2rYc8crnwy4IuxtH3e/6nB IQyUaDpvPDIPYMwGIlx8tN6xW6yu8tW0faET9ngfr0iozwx/yP9TUn3uxXY8U8urGO YRpO0f+u/EDTvyQg2TtLaofyUzQ3R6NFaEzBAEHc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Peter Zijlstra (Intel)" , juri.lelli@arm.com, bigeasy@linutronix.de, xlpang@redhat.com, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jdesfossez@efficios.com, dvhart@infradead.org, bristot@redhat.com, Thomas Gleixner , Zubin Mithra Subject: [PATCH 4.4 115/230] futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock() Date: Fri, 22 Mar 2019 12:14:13 +0100 Message-Id: <20190322111244.718155150@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190322111236.796964179@linuxfoundation.org> References: <20190322111236.796964179@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Peter Zijlstra commit 38d589f2fd08f1296aea3ce62bebd185125c6d81 upstream. With the ultimate goal of keeping rt_mutex wait_list and futex_q waiters consistent it's necessary to split 'rt_mutex_futex_lock()' into finer parts, such that only the actual blocking can be done without hb->lock held. Split split_mutex_finish_proxy_lock() into two parts, one that does the blocking and one that does remove_waiter() when the lock acquire failed. When the rtmutex was acquired successfully the waiter can be removed in the acquisiton path safely, since there is no concurrency on the lock owner. This means that, except for futex_lock_pi(), all wait_list modifications are done with both hb->lock and wait_lock held. [bigeasy@linutronix.de: fix for futex_requeue_pi_signal_restart] Signed-off-by: Peter Zijlstra (Intel) Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: dvhart@infradead.org Cc: bristot@redhat.com Link: http://lkml.kernel.org/r/20170322104152.001659630@infradead.org Signed-off-by: Thomas Gleixner Signed-off-by: Zubin Mithra Signed-off-by: Greg Kroah-Hartman --- kernel/futex.c | 7 +++-- kernel/locking/rtmutex.c | 52 ++++++++++++++++++++++++++++++++++------ kernel/locking/rtmutex_common.h | 8 +++--- 3 files changed, 55 insertions(+), 12 deletions(-) --- a/kernel/futex.c +++ b/kernel/futex.c @@ -2923,10 +2923,13 @@ static int futex_wait_requeue_pi(u32 __u */ WARN_ON(!q.pi_state); pi_mutex = &q.pi_state->pi_mutex; - ret = rt_mutex_finish_proxy_lock(pi_mutex, to, &rt_waiter); - debug_rt_mutex_free_waiter(&rt_waiter); + ret = rt_mutex_wait_proxy_lock(pi_mutex, to, &rt_waiter); spin_lock(q.lock_ptr); + if (ret && !rt_mutex_cleanup_proxy_lock(pi_mutex, &rt_waiter)) + ret = 0; + + debug_rt_mutex_free_waiter(&rt_waiter); /* * Fixup the pi_state owner and possibly acquire the lock if we * haven't already. --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -1712,21 +1712,23 @@ struct task_struct *rt_mutex_next_owner( } /** - * rt_mutex_finish_proxy_lock() - Complete lock acquisition + * rt_mutex_wait_proxy_lock() - Wait for lock acquisition * @lock: the rt_mutex we were woken on * @to: the timeout, null if none. hrtimer should already have * been started. * @waiter: the pre-initialized rt_mutex_waiter * - * Complete the lock acquisition started our behalf by another thread. + * Wait for the the lock acquisition started on our behalf by + * rt_mutex_start_proxy_lock(). Upon failure, the caller must call + * rt_mutex_cleanup_proxy_lock(). * * Returns: * 0 - success * <0 - error, one of -EINTR, -ETIMEDOUT * - * Special API call for PI-futex requeue support + * Special API call for PI-futex support */ -int rt_mutex_finish_proxy_lock(struct rt_mutex *lock, +int rt_mutex_wait_proxy_lock(struct rt_mutex *lock, struct hrtimer_sleeper *to, struct rt_mutex_waiter *waiter) { @@ -1739,9 +1741,6 @@ int rt_mutex_finish_proxy_lock(struct rt /* sleep on the mutex */ ret = __rt_mutex_slowlock(lock, TASK_INTERRUPTIBLE, to, waiter); - if (unlikely(ret)) - remove_waiter(lock, waiter); - /* * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. @@ -1752,3 +1751,42 @@ int rt_mutex_finish_proxy_lock(struct rt return ret; } + +/** + * rt_mutex_cleanup_proxy_lock() - Cleanup failed lock acquisition + * @lock: the rt_mutex we were woken on + * @waiter: the pre-initialized rt_mutex_waiter + * + * Attempt to clean up after a failed rt_mutex_wait_proxy_lock(). + * + * Unless we acquired the lock; we're still enqueued on the wait-list and can + * in fact still be granted ownership until we're removed. Therefore we can + * find we are in fact the owner and must disregard the + * rt_mutex_wait_proxy_lock() failure. + * + * Returns: + * true - did the cleanup, we done. + * false - we acquired the lock after rt_mutex_wait_proxy_lock() returned, + * caller should disregards its return value. + * + * Special API call for PI-futex support + */ +bool rt_mutex_cleanup_proxy_lock(struct rt_mutex *lock, + struct rt_mutex_waiter *waiter) +{ + bool cleanup = false; + + raw_spin_lock_irq(&lock->wait_lock); + /* + * Unless we're the owner; we're still enqueued on the wait_list. + * So check if we became owner, if not, take us off the wait_list. + */ + if (rt_mutex_owner(lock) != current) { + remove_waiter(lock, waiter); + fixup_rt_mutex_waiters(lock); + cleanup = true; + } + raw_spin_unlock_irq(&lock->wait_lock); + + return cleanup; +} --- a/kernel/locking/rtmutex_common.h +++ b/kernel/locking/rtmutex_common.h @@ -106,9 +106,11 @@ extern void rt_mutex_proxy_unlock(struct extern int rt_mutex_start_proxy_lock(struct rt_mutex *lock, struct rt_mutex_waiter *waiter, struct task_struct *task); -extern int rt_mutex_finish_proxy_lock(struct rt_mutex *lock, - struct hrtimer_sleeper *to, - struct rt_mutex_waiter *waiter); +extern int rt_mutex_wait_proxy_lock(struct rt_mutex *lock, + struct hrtimer_sleeper *to, + struct rt_mutex_waiter *waiter); +extern bool rt_mutex_cleanup_proxy_lock(struct rt_mutex *lock, + struct rt_mutex_waiter *waiter); extern int rt_mutex_timed_futex_lock(struct rt_mutex *l, struct hrtimer_sleeper *to); extern bool rt_mutex_futex_unlock(struct rt_mutex *lock, struct wake_q_head *wqh);