From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-20.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F9E1C433F5 for ; Thu, 9 Sep 2021 08:34:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 32DEB60FC0 for ; Thu, 9 Sep 2021 08:34:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231756AbhIIIfz (ORCPT ); Thu, 9 Sep 2021 04:35:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49926 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230250AbhIIIfx (ORCPT ); Thu, 9 Sep 2021 04:35:53 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 889C6C061575; Thu, 9 Sep 2021 01:34:44 -0700 (PDT) Date: Thu, 09 Sep 2021 08:34:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1631176482; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=80QALolpCs7AaTRTKPDWXh+r0eyW85Gk82eTC53eMPI=; b=WUCpLxMzdK3se/kKe+cGQdxJecKcpXqI/3a5bpJ6ab5CtD86aXHJ+wVL2s6iIhPsn1VIIf hLjeuSW/5JjLfGcBUFMCA/ztYcmp1OvSmmMWxK7gj/3EU0KFuKKbhPYkRlH2/8LU0zgLqB vOk7yOtb9iG956q+Un/q4n8mNr2R4xNpl+2jRTvZ9UMM3gKOjWZFpuIC+l8kZrDLA09Uvn DbQvh8Vo5lQdfj9S3MWDUkTJQTEKvfxeYk65kYO8HhNHnMgcq/hs0lEQh+GA8N8PgxypwL DrrmODycdhTsBsdEeQEMCbB5y02qqzT6dtRiBLpS/NJjyy28ti4ksi5dBCNk3Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1631176482; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=80QALolpCs7AaTRTKPDWXh+r0eyW85Gk82eTC53eMPI=; b=AFZ5wdrtNb/depnNpKLuv0tU30vHuHBqydht30pbQqaBCPk542QrgSlWQ54c45FnOVr3A4 149EmsIc7zPm9tCA== From: "tip-bot2 for Peter Zijlstra" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: locking/urgent] locking/rtmutex: Fix ww_mutex deadlock check Cc: Dan Carpenter , "Peter Zijlstra (Intel)" , Thomas Gleixner , Sebastian Andrzej Siewior , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: MIME-Version: 1.0 Message-ID: <163117648132.25758.8161104732621115882.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the locking/urgent branch of tip: Commit-ID: e5480572706da1b2c2dc2c6484eab64f92b9263b Gitweb: https://git.kernel.org/tip/e5480572706da1b2c2dc2c6484eab64f92b9263b Author: Peter Zijlstra AuthorDate: Wed, 01 Sep 2021 11:44:11 +02:00 Committer: Thomas Gleixner CommitterDate: Thu, 09 Sep 2021 10:31:22 +02:00 locking/rtmutex: Fix ww_mutex deadlock check Dan reported that rt_mutex_adjust_prio_chain() can be called with .orig_waiter == NULL however commit a055fcc132d4 ("locking/rtmutex: Return success on deadlock for ww_mutex waiters") unconditionally dereferences it. Since both call-sites that have .orig_waiter == NULL don't care for the return value, simply disable the deadlock squash by adding the NULL check. Notably, both callers use the deadlock condition as a termination condition for the iteration; once detected, it is sure that (de)boosting is done. Arguably step [3] would be a more natural termination point, but it's dubious whether adding a third deadlock detection state would improve the code. Fixes: a055fcc132d4 ("locking/rtmutex: Return success on deadlock for ww_mutex waiters") Reported-by: Dan Carpenter Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Acked-by: Sebastian Andrzej Siewior Link: https://lore.kernel.org/r/YS9La56fHMiCCo75@hirez.programming.kicks-ass.net --- kernel/locking/rtmutex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 8eabdc7..6bb116c 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -753,7 +753,7 @@ static int __sched rt_mutex_adjust_prio_chain(struct task_struct *task, * other configuration and we fail to report; also, see * lockdep. */ - if (IS_ENABLED(CONFIG_PREEMPT_RT) && orig_waiter->ww_ctx) + if (IS_ENABLED(CONFIG_PREEMPT_RT) && orig_waiter && orig_waiter->ww_ctx) ret = 0; raw_spin_unlock(&lock->wait_lock);