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=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 5D174C31E40 for ; Mon, 12 Aug 2019 13:03:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 32DC320842 for ; Mon, 12 Aug 2019 13:03:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="PwGI0wkw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728816AbfHLNDO (ORCPT ); Mon, 12 Aug 2019 09:03:14 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:39032 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728813AbfHLNDN (ORCPT ); Mon, 12 Aug 2019 09:03:13 -0400 Received: by mail-pf1-f193.google.com with SMTP id f17so45669515pfn.6 for ; Mon, 12 Aug 2019 06:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=9PGFo0IOTBF0bIx7y/QxiVY31P4bvTcKQoBfJqZTG+w=; b=PwGI0wkwa6ZBvzJS2WowZtgp5DVi7QPH+BrB9p0HCfQcxpdzKqQgPTHdIAl3D1o9Ui UwguTSYRYWuAd3qrqhfjY+51MrRtaJizalVxHqxwXrlJqDBvavY40TWKCBgS4IeFRTPK AfF57tOE8WhINap7lLBY+lYVRyduY9cx0H4rc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=9PGFo0IOTBF0bIx7y/QxiVY31P4bvTcKQoBfJqZTG+w=; b=ljDtD7AXhzc/wIKpE67ESGiA9LZ7u0rh/HlVMHO32jfpzgt5d3MehYTIe3m6+Nlgij Bz7yBY4zgq9XOzNu53r+iH4o4Ydg8/FiMsonOWvmCY9r8dekN3mc3EZ08L00WIA5bIJb qcmfNOGyM473oumyzphuMI37B3QJrMHvWKuogAZX/oNU9Htr9tl4DsfOKNh1bcDB5Oib LXpqX1F5Fh0fQIB+KH+qx8BMLz2rGdeVAywrbi20gmOJxFqVgVbwB9BTgACIJCgpSEH0 ca5I1SFtaxXQO6YPpTCVmjpb6z8idpTJO2/fppskZ7x7iFQ79SJ6qSw2Hjjj/dL0MGjc 1aZA== X-Gm-Message-State: APjAAAWktIjf7tKZcLjCeYXXULCi0KB2EylvNkp3ZV41/57JPxWSZGuJ 9QS5lrf7w+91V9tWexOQXThb2w== X-Google-Smtp-Source: APXvYqyz6EmE0iTkl3gZlNovk6A/dv0bMJdkggbBqQc3eqErF9H/OyeJ1CsBomxTPL6iok8vEgG0pQ== X-Received: by 2002:a17:90a:ec07:: with SMTP id l7mr18571059pjy.39.1565614992605; Mon, 12 Aug 2019 06:03:12 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id o3sm25222103pje.1.2019.08.12.06.03.11 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 12 Aug 2019 06:03:11 -0700 (PDT) Date: Mon, 12 Aug 2019 09:03:10 -0400 From: Joel Fernandes To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, kbuild test robot , Jonathan Corbet , Josh Triplett , Lai Jiangshan , linux-doc@vger.kernel.org, Mathieu Desnoyers , "Paul E. McKenney" , "Rafael J. Wysocki" , rcu@vger.kernel.org, Steven Rostedt , Tejun Heo Subject: Re: [PATCH 3/3] driver/core: Fix build error when SRCU and lockdep disabled Message-ID: <20190812130310.GA27552@google.com> References: <20190811221111.99401-1-joel@joelfernandes.org> <20190811221111.99401-3-joel@joelfernandes.org> <20190812050256.GC5834@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190812050256.GC5834@kroah.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: rcu-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org On Mon, Aug 12, 2019 at 07:02:56AM +0200, Greg Kroah-Hartman wrote: > On Sun, Aug 11, 2019 at 06:11:11PM -0400, Joel Fernandes (Google) wrote: > > Properly check if lockdep lock checking is disabled at config time. If > > so, then lock_is_held() is undefined so don't do any checking. > > > > This fix is similar to the pattern used in srcu_read_lock_held(). > > > > Link: https://lore.kernel.org/lkml/201908080026.WSAFx14k%25lkp@intel.com/ > > Fixes: c9e4d3a2fee8 ("acpi: Use built-in RCU list checking for acpi_ioremaps list") > > What tree is this commit in? > > > Reported-by: kbuild test robot > > Signed-off-by: Joel Fernandes (Google) > > --- > > This patch is based on the -rcu dev branch. > > Ah... > > > drivers/base/core.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > index 32cf83d1c744..fe25cf690562 100644 > > --- a/drivers/base/core.c > > +++ b/drivers/base/core.c > > @@ -99,7 +99,11 @@ void device_links_read_unlock(int not_used) > > > > int device_links_read_lock_held(void) > > { > > - return lock_is_held(&device_links_lock); > > +#ifdef CONFIG_DEBUG_LOCK_ALLOC > > + return lock_is_held(&(device_links_lock.dep_map)); > > +#else > > + return 1; > > +#endif > > return 1? So the lock is always held? This is just the pattern of an assert that is disabled, so that false-positives don't happen if lockdep is disabled. So say someone writes a statement like: WARN_ON_ONCE(!device_links_read_lock_held()); Since lockdep is disabled, we cannot check whether lock is held or not. Yet, we don't want false positives by reporting that the lock is not held. In this case, it is better to report that the lock is held to suppress false-positives. srcu_read_lock_held() also follows the same pattern. thanks, - Joel