Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4929389pxb; Mon, 15 Feb 2021 05:16:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJzdQ/Tml4159YEPuFOGLWgjYPFERpA09nbdEWf+eAEYHfeEirMBjalTnBPeKnsn6KTV6bvC X-Received: by 2002:a17:907:11c7:: with SMTP id va7mr15515085ejb.351.1613394965631; Mon, 15 Feb 2021 05:16:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613394965; cv=none; d=google.com; s=arc-20160816; b=H0r68bAMLbURPXkJ1+4xkBJs8a+c/gB+k3B4eKmJm/r9qcSYnZ6Ckg4pufeSHKRqRi qxSn/K1dNNbjzrMEJZiQdxT7G4B0XW/TBzbPXuA/1Mxz6nZbGEyr2FxbaVgxa0muHzQ6 R1VbiWKnnvSqCX+9HBk8Z4p96fJkQDwKyUhYrT/+R9PBswU0RiLPiRrq6YJ6qiCF8aNr jg9jQHdFNpl9zus/+hcQUoCRUGAJsBz9+vNx+9S+eOg6tNyQ15Q+HJ5Ixo+l7YfTa76G 4R6zDeXL90OmJIRv7DougAmfZ2EctJWRVOQlZixcZeY4iIWQulfztNnMe9SIT8utjn0i qFIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=2uNN+vJgNSTmvDikwlCs+Sh7Bxy/iBYPdwzJ0bf6dCo=; b=ZaqeW6dAeIDp/P+GAGxR+xjVcL0EB0D1GLl3j0EfbgtaxdD9A3wEz7yfQTxArPqq+f QI+A4LVs0gYxA8gcjQMWHMa61jnFHAC3ZpaCXI8gQiMXK0UFV2y8nXtclyR7YSA6u9E1 w7m1YHZoyqHdSjI090/ho1KBNLIFHbaZeD+aMzlO1AZYGgPCFjtvhsaL5kchB0vjxHMW pbxYaA00oM7+MluF9LAvrP3tG69r+WEa4cA/5M93N/DzUjILplP+PbZa6gKNYF1OoSBG XGCnnsU++ImHBA4+VZtC5n9N4FIFVx9cFDLzYZnv9ja1kEWVShDPO7hdOi0TMl/PyR7S HK5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g5si13012510edj.194.2021.02.15.05.15.42; Mon, 15 Feb 2021 05:16:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230090AbhBONOB (ORCPT + 99 others); Mon, 15 Feb 2021 08:14:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230233AbhBONNu (ORCPT ); Mon, 15 Feb 2021 08:13:50 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A9CDC061574; Mon, 15 Feb 2021 05:13:07 -0800 (PST) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1lBdgE-003Frr-1U; Mon, 15 Feb 2021 14:12:46 +0100 Message-ID: <79aeb83a288051bd3a2a3f15e5ac42e06f154d48.camel@sipsolutions.net> Subject: Re: [PATCH 1/2] lockdep: add lockdep_assert_not_held() From: Johannes Berg To: Peter Zijlstra , Shuah Khan Cc: mingo@redhat.com, will@kernel.org, kvalo@codeaurora.org, davem@davemloft.net, kuba@kernel.org, ath10k@lists.infradead.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 15 Feb 2021 14:12:30 +0100 In-Reply-To: <20210215104402.GC4507@worktop.programming.kicks-ass.net> (sfid-20210215_114645_090502_64B4A89D) References: <37a29c383bff2fb1605241ee6c7c9be3784fb3c6.1613171185.git.skhan@linuxfoundation.org> <20210215104402.GC4507@worktop.programming.kicks-ass.net> (sfid-20210215_114645_090502_64B4A89D) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2021-02-15 at 11:44 +0100, Peter Zijlstra wrote: > > I think something like so will work, but please double check. Yeah, that looks better. > +++ b/include/linux/lockdep.h > @@ -294,11 +294,15 @@ extern void lock_unpin_lock(struct lockdep_map *lock, struct pin_cookie); > > #define lockdep_depth(tsk) (debug_locks ? (tsk)->lockdep_depth : 0) > > -#define lockdep_assert_held(l) do { \ > - WARN_ON(debug_locks && !lockdep_is_held(l)); \ > +#define lockdep_assert_held(l) do { \ > + WARN_ON(debug_locks && lockdep_is_held(l) == 0)); \ > } while (0) That doesn't really need to change? It's the same. > -#define lockdep_assert_held_write(l) do { \ > +#define lockdep_assert_not_held(l) do { \ > + WARN_ON(debug_locks && lockdep_is_held(l) == 1)); \ > + } while (0) > + > +#define lockdep_assert_held_write(l) do { \ > WARN_ON(debug_locks && !lockdep_is_held_type(l, 0)); \ > } while (0) > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index c1418b47f625..983ba206f7b2 100644 > --- a/kernel/locking/lockdep. > +++ b/kernel/locking/lockdep.c > @@ -5467,7 +5467,7 @@ noinstr int lock_is_held_type(const struct lockdep_map *lock, int read) > int ret = 0; > > if (unlikely(!lockdep_enabled())) > - return 1; /* avoid false negative lockdep_assert_held() */ > + return -1; /* avoid false negative lockdep_assert_held() */ Maybe add lockdep_assert_not_held() to the comment, to explain the -1 (vs non-zero)? johannes