On Mon, Nov 21 2016 at 6:57pm -0500, Bart Van Assche <bart.vanass...@sandisk.com> wrote:
> On 11/21/2016 03:43 PM, Mike Snitzer wrote: > >Shouldn't be possible. The previous stacktrace you shared clearly > >showed that the DM mpath request_queue was using blk-mq (dm_mq_queue_rq > >was in the stack). > > > >Whereas the stacktrace above is clearly the old request_fn interface. > > > >I'm unaware of how the existing code can allow this. As I said in my > >earlier mails on this: the request-queue shouldn't be able to change > >from blk-mq back to .request_fn or vice-versa. > > > >So if you think you're only testing blk-mq DM mpath on blk-mq paths, > >then you need to determine how dm_old_init_request_queue() is getting > >called to even setup .request_fn (dm_old_request_fn) to be used. > > > >If the opposite is true (old request_fn DM mpath stack on blk-mq paths) > >then determine how dm_mq_init_request_queue is getting called. > > > >Basically dm_setup_md_queue() should only ever be called the first time > >the "multipath" target is loaded. If that isn't the case, then you've > >exposed some seriously weird bug/regression. > > Hello Mike, > > Sorry that I had not yet mentioned this, but the test I'm running is > as follows: > > # while true; do for t in mq sq sq-on-mq; do echo ==== $t; > srp-test/run_tests -s -t 02-$t; done But you WARN_ON_ONCE(clone && q->mq_ops) will trigger with sq-on-mq. So this would seem to be a false positive. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
