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;
Date:   Mon, 12 Aug 2019 16:01:25 -0400
From:   Joel Fernandes <joel@joelfernandes.org>
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, kbuild test robot <lkp@intel.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Josh Triplett <josh@joshtriplett.org>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        linux-doc@vger.kernel.org,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        "Paul E. McKenney" <paulmck@linux.ibm.com>,
        "Rafael J. Wysocki" <rafael@kernel.org>, rcu@vger.kernel.org,
        Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 3/3] driver/core: Fix build error when SRCU and lockdep
 disabled
Message-ID: <20190812200125.GA161786@google.com>
References: <20190811221111.99401-1-joel@joelfernandes.org>
 <20190811221111.99401-3-joel@joelfernandes.org>
 <20190812050256.GC5834@kroah.com>
 <20190812130310.GA27552@google.com>
 <20190812141119.6ec00a34@gandalf.local.home>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190812141119.6ec00a34@gandalf.local.home>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 12, 2019 at 02:11:19PM -0400, Steven Rostedt wrote:
> On Mon, 12 Aug 2019 09:03:10 -0400
> Joel Fernandes <joel@joelfernandes.org> wrote:
> 
>   
> > > >  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?  
> 
> I was thinking the exact same thing.
> 
> > 
> > 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.
> > 
> 
> The real answer here is to make that WARN_ON_ONCE() dependent on
> lockdep. Something like:
> 
> 
> some/header/file.h:
> 
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> # define CHECK_DEVICE_LINKS_READ_LOCK_HELD() WARN_ON_ONCE(!defice_links_read_lock_held())
> #else
> # define CHECK_DEVICE_LINKS_READ_LOCK_HELD() do { } while (0)
> #endif
> 
> And just use CHECK_DEVICE_LINK_READ_LOCK_HELD() in those places. I
> agree with Greg. "device_links_read_lock_heald()" should *never*
> blindly return 1. It's confusing.

Ok, then I will update the patch to do:

#ifdef CONFIG_DEBUG_LOCK_ALLOC
int device_links_read_lock_held(void)
{
	return lock_is_held(&device_links_lock);
}
#endif  

That will also solve the build error. And callers can follow the above pattern you shared.

thanks,

 - Joel