linux-kernel - Re: [PATCH 3/3] driver/core: Fix build error when SRCU and lockdep disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190812141119.6ec00a34@gandalf.local.home>
Date:   Mon, 12 Aug 2019 14:11:19 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, kbuild test robot <lkp@...el.com>,
        Jonathan Corbet <corbet@....net>,
        Josh Triplett <josh@...htriplett.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        linux-doc@...r.kernel.org,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        "Paul E. McKenney" <paulmck@...ux.ibm.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>, rcu@...r.kernel.org,
        Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH 3/3] driver/core: Fix build error when SRCU and lockdep
 disabled

On Mon, 12 Aug 2019 09:03:10 -0400
Joel Fernandes <joel@...lfernandes.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.

-- Steve