Ok, I figured this out. Bisecting took me to 5f65753033d8c5a53e65810bff3832e8282c68d1, which seems unrelated, but blocks open (and open recover) code paths from being run, so the real culprit is two commits back e23008ec81ef37b7b271669ce5d2de2643b2dc75. I changed the order of these patches and verified that e23008ec81ef37b7b271669ce5d2de2643b2dc75 introduces the NULL dereference. e23008ec81ef37b7b271669ce5d2de2643b2dc75 is in all tags since v3.7. Trond: Please CC stable with a note that this is for v3.7+. I'll add the CC if I need to repost upon review. -dros On Oct 15, 2013, at 1:43 PM, Weston Andros Adamson <dros@xxxxxxxxxx> wrote: > I plan on bisecting this next time I get a few spare cycles. > > -dros > > On Oct 14, 2013, at 11:51 AM, William Dauchy <wdauchy@xxxxxxxxx> wrote: > >> On Tue, Oct 8, 2013 at 1:40 AM, Weston Andros Adamson <dros@xxxxxxxxxx> wrote: >>> This is the bug I found at the bakeathon. I can finally reproduce it quickly! And in a shockingly easy way! >>> Tomorrow I'll figure out how long this regression has been present and if we need to CC stable. >> >> Any news on that? Does it apply on older version? >> >> Thanks, >> >> -- >> William > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
