Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4784773imm; Tue, 9 Oct 2018 05:20:38 -0700 (PDT) X-Google-Smtp-Source: ACcGV63d6zjcGcIAPFLGeQeweU7RIL4KQ1mez4F10C2qHyb1cyslhiTliDe31kxVi0XLaFStvsd8 X-Received: by 2002:a62:12c9:: with SMTP id 70-v6mr30058501pfs.140.1539087638237; Tue, 09 Oct 2018 05:20:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539087638; cv=none; d=google.com; s=arc-20160816; b=tOCMEiM4QkRntnILO7VkbXIoNWZZaTvroxFOSIvtieSiUz23aXp7Q9RGBaGixcpAQz MOdH0+NeUTXhpk8/f/fH8So56mbSXvoV6CQIB0MGApraAGyV2CsVWc5zB0l7qeM+xWsG RXyYClCLBrNAvRV8mwCKXojIKO5o8Gxs2HX7rHwoSExsotKEd1LPD18WzbYP2CMb+SXL OVpH23fZ9+B1TQIcEgtbvJ1gzoJtznYDLK7TfBzWrvDMcNq0jtl3scR5DR/fMLNsX+k3 zmHLMkIAlA3+ndVkr/tELa43+8yRuFFhP/auwAuKyyBlBoJ3nsq8f0UE+3Tck887O5mZ pksw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=LVh59vVL0t6yjrlGzuc5+sJ3LXSTPCE6YMQUPhD1GDU=; b=IzmH3Cce1uLOcrmlxUnfLqeWgusFl+Exhjc+1VhlVDFDmQ2JXoDB1o8qPUOHc1KPkZ Jg5wWtlSWzcFJ2gdprqDayMCzQ/QlCd0r6qUN+JZPf+33BCkwq8FRW0qsPtrwF3ks/oe 0tmsw3ulEk6YJ6D2+NA62cVy9oY1XhEdhowhaQzLy1rD6Ltd2SQEzsb165IMpA7FQn+p X2y71nigzbvax80pdvtvvcQEWhgxE0rNlJPnqakADuqwr/tzLvCPmY8JSAFjci/3tAzD 6E2E3o54KGsk1nvqRCXi9Fn0HHfVZnDzsbZVGHPa2DHA70ntHYbd2Pxx7HMh8QpqJmZW VWoA== 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 l185-v6si18121233pfl.104.2018.10.09.05.20.23; Tue, 09 Oct 2018 05:20:38 -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; 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 S1726862AbeJITew (ORCPT + 99 others); Tue, 9 Oct 2018 15:34:52 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:36908 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726485AbeJITew (ORCPT ); Tue, 9 Oct 2018 15:34:52 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2CB887A9; Tue, 9 Oct 2018 05:18:11 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F22AA3F5B3; Tue, 9 Oct 2018 05:18:10 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 44E771AE0876; Tue, 9 Oct 2018 13:18:10 +0100 (BST) Date: Tue, 9 Oct 2018 13:18:10 +0100 From: Will Deacon To: Lance Roy Cc: linux-kernel@vger.kernel.org, "Paul E. McKenney" , Peter Zijlstra , Ingo Molnar Subject: Re: [PATCH 12/16] locking/mutex: Replace spin_is_locked() with lockdep Message-ID: <20181009121809.GG6248@arm.com> References: <20181003053902.6910-1-ldr709@gmail.com> <20181003053902.6910-13-ldr709@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181003053902.6910-13-ldr709@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 02, 2018 at 10:38:58PM -0700, Lance Roy wrote: > lockdep_assert_held() is better suited to checking locking requirements, > since it won't get confused when someone else holds the lock. This is > also a step towards possibly removing spin_is_locked(). > > Signed-off-by: Lance Roy > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Will Deacon > --- > kernel/locking/mutex-debug.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c > index 9aa713629387..771d4ca96dda 100644 > --- a/kernel/locking/mutex-debug.c > +++ b/kernel/locking/mutex-debug.c > @@ -36,7 +36,7 @@ void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter) > > void debug_mutex_wake_waiter(struct mutex *lock, struct mutex_waiter *waiter) > { > - SMP_DEBUG_LOCKS_WARN_ON(!spin_is_locked(&lock->wait_lock)); > + lockdep_assert_held(&lock->wait_lock); > DEBUG_LOCKS_WARN_ON(list_empty(&lock->wait_list)); > DEBUG_LOCKS_WARN_ON(waiter->magic != waiter); > DEBUG_LOCKS_WARN_ON(list_empty(&waiter->list)); > @@ -51,7 +51,7 @@ void debug_mutex_free_waiter(struct mutex_waiter *waiter) > void debug_mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter, > struct task_struct *task) > { > - SMP_DEBUG_LOCKS_WARN_ON(!spin_is_locked(&lock->wait_lock)); > + lockdep_assert_held(&lock->wait_lock); I think it's a good idea to replace debug usage of spin_is_locked() with calls to lockdep, but I wonder whether that means that DEBUG_MUTEXES should select LOCKDEP so that we don't lose coverage? What do you think? Will