On 09/10/2014 09:08 AM, Peter Zijlstra wrote:

On Wed, Sep 10, 2014 at 07:02:10AM -0400, Peter Hurley wrote:

quoted

On 09/04/2014 01:14 AM, Ingo Molnar wrote:

quoted

* Peter Zijlstra [off-list ref] wrote:

quoted

On Wed, Sep 03, 2014 at 10:50:01AM -0400, Peter Hurley wrote:

quoted

So a lockdep-only assert is unlikely to draw attention to existing bugs,
especially in established drivers.

By the same logic lockdep will not find locking errors in established
drivers.

Indeed, this patch is ill-advised in several ways:

  - it extends an API variant that we want to phase

  - emits a warning even if say lockdep has already emitted a
    warning and locking state is not guaranteed to be consistent. 

  - makes the kernel more expensive once fully debugged, in that
    non-fatal checks are unconditional.

Ok.

One thing: I'm not seeing how lockdep_assert_held() switches off once
the warning has been emitted? Is the caller expected to construct their
own _ONCE tags?

Indeed, it does not do that. I suppose you can add
lockdep_assert_held_once() or somesuch if you think the once thing is
important.

Ok, will do.

On 09/04/2014 01:14 AM, Ingo Molnar wrote:

Also please submit locking related patches as standalone series 
to the locking subsystem, not embedded in an unrelated series.

Ok, but how will Greg know when to take the series that depends on
this change, if the locking change is submitted separately?

Regards,
Peter Hurley