mtip32x: fix regression introduced by blk-mq per-hctx flush
authorJeff Moyer <jmoyer@redhat.com>
Wed, 29 Jul 2015 14:22:50 +0000 (10:22 -0400)
committerJens Axboe <axboe@fb.com>
Tue, 25 Aug 2015 20:35:51 +0000 (14:35 -0600)
commit74c9c9134bf8d8a6d5c5683f60262eed3d6fb5ac
tree03c2a5877c6fc49236a9e232573d605eaf70de40
parent006a0973ed020a81fe1f24b511ce9feb53f70e44
mtip32x: fix regression introduced by blk-mq per-hctx flush

Hi,

After commit f70ced091707 (blk-mq: support per-distpatch_queue flush
machinery), the mtip32xx driver may oops upon module load due to walking
off the end of an array in mtip_init_cmd.  On initialization of the
flush_rq, init_request is called with request_index >= the maximum queue
depth the driver supports.  For mtip32xx, this value is used to index
into an array.  What this means is that the driver will walk off the end
of the array, and either oops or cause random memory corruption.

The problem is easily reproduced by doing modprobe/rmmod of the mtip32xx
driver in a loop.  I can typically reproduce the problem in about 30
seconds.

Now, in the case of mtip32xx, it actually doesn't support flush/fua, so
I think we can simply return without doing anything.  In addition, no
other mq-enabled driver does anything with the request_index passed into
init_request(), so no other driver is affected.  However, I'm not really
sure what is expected of drivers.  Ming, what did you envision drivers
would do when initializing the flush requests?

Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
drivers/block/mtip32xx/mtip32xx.c