On Thu, Feb 02 2017 at 4:04pm -0500, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > On Thu, Feb 02 2017 at 2:46pm -0500, > Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx> wrote: > > > On Thu, 2017-02-02 at 14:13 -0500, Mike Snitzer wrote: > > > On Thu, Feb 02 2017 at 1:43pm -0500, Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx> wrote: > > > > On Thu, 2017-02-02 at 13:33 -0500, Mike Snitzer wrote: > > > > > I'll go back over hch's changes to see if I can spot anything. But is > > > > > this testing using dm_mod.use_bk_mq=Y or are you testing old .request_fn > > > > > dm-multipath? > > > > > > > > The srp-test software tests multiple configurations: dm-mq on scsi-mq, dm-sq > > > > on scsi-mq and dm-sq on scsi-sq. I have not yet checked which of these > > > > three configurations triggers the kernel crash. > > > > > > OK, such info is important to provide for crashes like this. Please let > > > me know once you do. > > > > Hello Mike, > > > > Apparently it's the large I/O test (using dm-mq on scsi-mq) that triggers the > > crash: > > I've gone over Christoph's "dm: always defer request allocation to the > owner of the request_queue" commit yet again. Most of that commit's > changes are just mechanical. I didn't see any problems. > > In general, dm_start_request() calls dm_get(md) to take a reference on > the mapped_device. And rq_completed() calls dm_put(md) to drop the > reference. The DM device's request_queue (md->queue) should _not_ ever > be torn down before all references on the md have been dropped. But I'll > have to look closer on how/if that is enforced anywhere by coordinating > with block core. > > In any case, the crash you reported was that the mapped_device was being > dereferenced after it was freed (at line 187's md->queue). Which seems > to imply a dm_get/dm_put reference count regression. But I'm not seeing > where at this point. Maybe it isn't a regression but something about Christoph's changes causes a race to present itself? Care to try moving the dm_get(md) at the end of dm_start_request() to the beginning of dm_start_request() and report back on whether it helps at all? Thanks, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
