Re: bcache oops in bch_insert_data with the latest stables fixes (3.10.15)

[Kent Overstreet <kmo@daterainc.com>]

On Wed, Oct 09, 2013 at 02:25:52PM -0700, Greg KH wrote:
> On Tue, Oct 08, 2013 at 03:32:21PM -0700, Kent Overstreet wrote:
> > On Wed, Oct 09, 2013 at 12:13:56AM +0200, Gabriel de Perthuis wrote:
> > > Le 06/10/2013 17:50, Gabriel de Perthuis a écrit :
> > > > Le 06/10/2013 12:38, Cyril B. a écrit :
> > > >> Hello,
> > > >>
> > > >> I get the following oops immediately after booting on 3.10.15.
> > > >> Everything works fine in 3.10.10. Both the backing and cache devices are
> > > >> on top of mdadm.
> > > > 
> > > > Reverting c0f04d88e46d14de51f4baebb6efafb7d59e9f96 fixes it; it was one
> > > > of the few commits that's in 3.12 and -stable but not in
> > > > bcache-for-3.11.  That commit causes bch_insert_data to be called with
> > > > an unset op.cache_bio.
> > > 
> > > Pinging stable,
> > > http://git.kernel.org/linus/c0f04d88e46d14de51f4baebb6efafb7d59e9f96
> > > should be reverted.  It was in 3.11.4 and 3.10.15 (and 3.12-rc3).
> > > It breaks bcache's writeback mode by calling bch_writeback_data without
> > > setting cache_bio (it's more visible here[1]).  There's a bit of
> > > indirection through closure calls, but it could never work.
> > 
> > Greg - I screwed up on that patch (and I'm still scratching my head as
> > to how testing missed it) - it's a two line fix I'll be mailing off to
> > Linus shortly, or if you don't want to wait for that reverting it might
> > be better (though there was a data corruption bug that users reported
> > that fixed, so I'd be hesitent there):
> > 
> > Here's the fix I just mailed out, just waiting on a bit of outside
> > testing to mail it to Linus:
> > 
> > http://permalink.gmane.org/gmane.linux.kernel.bcache.devel/2113
> 
> I'll wait for the new patch to get into Linus's tree, so as to keep
> things synced up.  Let me know what the git commit it of the patch is
> when hit hits his tree and I'll add it to the next stable queue.

It's in - it's 2fe80d3bbf1c8bd9efc5b8154207c8dd104e7306. Thanks!