[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190812160507.61d60224@gandalf.local.home>
Date: Mon, 12 Aug 2019 16:05:07 -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 16:01:25 -0400
Joel Fernandes <joel@...lfernandes.org> wrote:
> > 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.
Sounds good!
-- Steve
Powered by blists - more mailing lists