On Fri, Oct 11, 2013 at 12:07:36AM -0700, Kent Overstreet wrote: > 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! Now applied, thanks for pointing it out. greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html