From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753773AbbG2Ook (ORCPT ); Wed, 29 Jul 2015 10:44:40 -0400 Received: from mail-pd0-f181.google.com ([209.85.192.181]:35174 "EHLO mail-pd0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751374AbbG2Ooj (ORCPT ); Wed, 29 Jul 2015 10:44:39 -0400 Message-ID: <55B8E6D6.7090809@kernel.dk> Date: Wed, 29 Jul 2015 08:44:38 -0600 From: Jens Axboe User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Jeff Moyer , Ming Lei , Sam Bradshaw , Asai Thambi SP CC: linux-kernel@vger.kernel.org, dmilburn@redhat.com Subject: Re: [patch|rfc] mtip32x: fix regression introduced by blk-mq per-hctx flush References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- Jens Axboe