[dm-devel] [PATCH 7/7] dm-mpath: Fix a race condition in __multipath_map()

Bart Van Assche bart.vanassche at sandisk.com
Mon Nov 21 23:57:24 UTC 2016


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

In other words, I'm alternating mq-on-mq, sq-on-sq and sq-on-mq tests. 
The above command does not log the time at which each test started so 
I'm not sure whether it is possible to determine which test triggered 
the call stack I posted in my previous e-mail.

Bart.




More information about the dm-devel mailing list