Re: shared/298 lockdep splat?

From	Byungchul Park <byungchul.park@lge.com>
Newsgroups	linux.kernel
Subject	Re: shared/298 lockdep splat?
Date	2017-09-26 09:10 +0200
Message-ID	<utSaf-1rM-41@gated-at.bofh.it> (permalink)
References	<urVFg-FH-15@gated-at.bofh.it> <urVFg-FH-13@gated-at.bofh.it> <us5lf-6XJ-1@gated-at.bofh.it> <utPcl-7D3-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Tue, Sep 26, 2017 at 01:51:49PM +1000, Dave Chinner wrote:
> On Thu, Sep 21, 2017 at 05:47:14PM +0900, Byungchul Park wrote:
> > On Thu, Sep 21, 2017 at 08:22:56AM +1000, Dave Chinner wrote:
> > > Peter, this is the sort of false positive I mentioned were likely to
> > > occur without some serious work to annotate the IO stack to prevent
> > > them.  We can nest multiple layers of IO completions and locking in
> > > the IO stack via things like loop and RAID devices.  They can be
> > > nested to arbitrary depths, too (e.g. loop on fs on loop on fs on
> > > dm-raid on n * (loop on fs) on bdev) so this new completion lockdep
> > > checking is going to be a source of false positives until there is
> > > an effective (and simple!) way of providing context based completion
> > > annotations to avoid them...
> > 
> > Hello,
> > 
> > It looks caused by that &ret.event in submit_bio_wait() is initialized
> > with the same class for all layers. I mean that completion variables in
> > different layers should be initialized with different classes, as you do
> > for typical locks in xfs.
> 
> Except that submit_bio_wait() is generic block layer functionality
> and can be used by anyone. Whatever solution you decide on, it has
> to be generic. And keep in mind that any code that submits a bio
> themselves and waits on a completion event from the bio is going to
> have to do their own annotations, which makes this a real PITA.

Right. Agree. Let me think it more. As you said, it should be generic.

> > I am not sure if I understand how xfs works correctly. Right? If yes,
> > how can we distinguish between independent 'bio's in submit_bio_wait()?
> > You or I can make it work with the answer. No?
> 
> Has nothing to do with XFS - it has no clue where it sits in the
> block device stack and has no business screwing with bio internals
> and stack layering to handle issues with stacked block devices....

Ok. Thank you for replying.

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: shared/298 lockdep splat? Dave Chinner <david@fromorbit.com> - 2017-09-21 00:30 +0200
  Re: shared/298 lockdep splat? Byungchul Park <byungchul.park@lge.com> - 2017-09-21 10:50 +0200
    Re: shared/298 lockdep splat? Dave Chinner <david@fromorbit.com> - 2017-09-26 06:00 +0200
      Re: shared/298 lockdep splat? Byungchul Park <byungchul.park@lge.com> - 2017-09-26 09:10 +0200

csiph-web