Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5947119ybl; Tue, 10 Dec 2019 14:15:18 -0800 (PST) X-Google-Smtp-Source: APXvYqzGC2YzNjB6dCbxwmUDWbbBrELMNleFx4xFZBC2skI6h/DSC/kp0l2Mts9UCQyXodx+WqPi X-Received: by 2002:a9d:4d8d:: with SMTP id u13mr16037otk.299.1576016118152; Tue, 10 Dec 2019 14:15:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576016118; cv=none; d=google.com; s=arc-20160816; b=oYC3juQP142B9lWMdCds2JbnG/fBs4lG1Qqj+A7dOiRNZL0H8KdVaM+gGdwfH22wHl 88usWHNRiylxl6Zq4niDLPAPddMf5WzEtfNnS+RiqIbSauPhki2GMmudjnYbNdCSbzn+ 76b4ThyRd20rbZpQXRfY3ObBUIXzAQdfE2nEp5lscNHiN+SkubmchiEeqLzil5hi9TDO PR2KtRpD+Uq6EEDBSzCd+K3rkWn6Dvf/l2e52hQmQCnMC3LbjGbGBE8yuyS3WQ5RSDhv XMIe6pIQ0qGc+kO+l0zjWsxS5TKIu1RTugy9J+d+bjOhuz5P+FOArD1pwCz49M4D5Y7j YWFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=KJpnjYs34LuAO7j2tL7Zpmgq/iLzRLwU1/y7mu/leXI=; b=w3Fq+aCbwMFqPad3sRfYbcEqd9qH2021Aw8NyHuHHXHmi3pmWeZz+0u7RjBIc1gtOl PSGy0i+oDA469JYmxG9ncqzYSn3IAYntrOTgw3D2zC0zet0Qnc/Rr7Js635a9zTJk1DA Tw1Ng1CdtJGIjc/E1tJ1GcnhhdyOtSDNAyYOyJ5HQiRIqaySjd3juVnmCiIMeOOm2Mqv EDVDRNZXPszQHEUxEms7kiEXPNC1WSk3YUKu0bBW+3qjE7jN3N+0/FyXj65sfN4JQvS7 Y5mxr5tgxX7kj41jEvnnuBV5tq+xDfFzhFY03cEM4h1IzT0uOj8QKGnJ0kPJcUgbZfPn JbOw== ARC-Authentication-Results: i=1; mx.google.com; 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 q6si2730865oti.173.2019.12.10.14.14.49; Tue, 10 Dec 2019 14:15:18 -0800 (PST) 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; 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 S1730270AbfLJWMu (ORCPT + 99 others); Tue, 10 Dec 2019 17:12:50 -0500 Received: from mx2.suse.de ([195.135.220.15]:60742 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729369AbfLJWMr (ORCPT ); Tue, 10 Dec 2019 17:12:47 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 903DCAD2B; Tue, 10 Dec 2019 22:12:45 +0000 (UTC) From: Davidlohr Bueso To: peterz@infradead.org Cc: dhowells@redhat.com, linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de, will@kernel.org, Davidlohr Bueso , Davidlohr Bueso Subject: [PATCH] Revert "locking/mutex: Complain upon mutex API misuse in IRQ contexts" Date: Tue, 10 Dec 2019 14:05:23 -0800 Message-Id: <20191210220523.28540-1-dave@stgolabs.net> X-Mailer: git-send-email 2.16.4 In-Reply-To: <20191210193011.GA11802@worktop.programming.kicks-ass.net> References: <20191210193011.GA11802@worktop.programming.kicks-ass.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This ended up causing some noise in places such as rxrpc running in softirq. The warning is misleading in this case as the mutex trylock and unlock operations are done within the same context; and therefore we need not worry about the PI-boosting issues that comes along with no single-owner lock guarantees. While we don't want to support this in mutexes, there is no way out of this yet; so lets get rid of the WARNs for now, as it is only fair to code that has historically relied on non-preemptible softirq guarantees. In addition, changing the lock type is also unviable: exclusive rwsems have the same issue (just not the WARN_ON) and counting semaphores would introduce a performance hit as mutexes are a lot more optimized. This reverts commit 5d4ebaa87329ef226e74e52c80ac1c62e4948987. Signed-off-by: Davidlohr Bueso --- kernel/locking/mutex.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c index 54cc5f9286e9..5352ce50a97e 100644 --- a/kernel/locking/mutex.c +++ b/kernel/locking/mutex.c @@ -733,9 +733,6 @@ static noinline void __sched __mutex_unlock_slowpath(struct mutex *lock, unsigne */ void __sched mutex_unlock(struct mutex *lock) { -#ifdef CONFIG_DEBUG_MUTEXES - WARN_ON(in_interrupt()); -#endif #ifndef CONFIG_DEBUG_LOCK_ALLOC if (__mutex_unlock_fast(lock)) return; @@ -1416,7 +1413,6 @@ int __sched mutex_trylock(struct mutex *lock) #ifdef CONFIG_DEBUG_MUTEXES DEBUG_LOCKS_WARN_ON(lock->magic != lock); - WARN_ON(in_interrupt()); #endif locked = __mutex_trylock(lock); -- 2.16.4