Messages in this thread | | | Subject | Re: [patch|rfc] mtip32x: fix regression introduced by blk-mq per-hctx flush | From | Jens Axboe <> | Date | Tue, 25 Aug 2015 14:36:55 -0600 |
| |
On 08/05/2015 02:44 PM, Jeff Moyer wrote: > Jens Axboe <axboe@kernel.dk> writes: > >> On 07/29/2015 08:22 AM, Jeff Moyer wrote: >>> 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? >> >> This is really a bug in the core, we should not have to work around >> this in the driver. I'll take a look at this. > > Hi, Jens, > > Any update on this?
To avoid stalling further on this, I'll apply the simple fix for 4.2 so we can move forward. It's a memory corruption issue and should get fixed, we can argue details later.
-- Jens Axboe
| |