lkml.org 
[lkml]   [2015]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch|rfc] mtip32x: fix regression introduced by blk-mq per-hctx flush
From
Date
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



\
 
 \ /
  Last update: 2015-08-25 23:01    [W:0.244 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site