On Wed, Sep 10, 2014 at 10:45:33AM -0400, Peter Hurley wrote: > On 09/10/2014 09:08 AM, Peter Zijlstra wrote: > > On Wed, Sep 10, 2014 at 07:02:10AM -0400, Peter Hurley wrote: > >> On 09/04/2014 01:14 AM, Ingo Molnar wrote: > >>> > >>> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > >>> > >>>> On Wed, Sep 03, 2014 at 10:50:01AM -0400, Peter Hurley wrote: > >>>>> 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? Cc: me on those changes, and I can track what happens with the tip tree where these would show up. Or wait a release cycle, that also is an easy way. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
