From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754482AbdEQXFX (ORCPT ); Wed, 17 May 2017 19:05:23 -0400 Received: from esa3.hgst.iphmx.com ([216.71.153.141]:55525 "EHLO esa3.hgst.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751957AbdEQXFV (ORCPT ); Wed, 17 May 2017 19:05:21 -0400 X-IronPort-AV: E=Sophos;i="5.38,356,1491235200"; d="scan'208";a="18431828" From: Bart Van Assche To: "jejb@linux.vnet.ibm.com" , "linux-scsi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "longli@microsoft.com" , "martin.petersen@oracle.com" CC: "sthemmin@microsoft.com" , "kys@microsoft.com" Subject: Re: [PATCH] scsi: zero per-cmd driver data for each MQ I/O Thread-Topic: [PATCH] scsi: zero per-cmd driver data for each MQ I/O Thread-Index: AdLN0Sb+ho4t8yK3r0qgJIjNbdRb6AABlBKAACSyIwAAPfMpgA== Date: Wed, 17 May 2017 23:05:18 +0000 Message-ID: <1495062317.2679.1.camel@sandisk.com> References: <1494892845.2567.14.camel@sandisk.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: linux.vnet.ibm.com; dkim=none (message not signed) header.d=none;linux.vnet.ibm.com; dmarc=none action=none header.from=sandisk.com; x-originating-ip: [63.163.107.100] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;BY1PR0401MB1532;7:/jaLIbq82P3+8ocDjkk/EN1nD5Htlh4XJUEuQaKfI7htL6Fapi84xZxLfKYhDL1/YSK7enSqb5gqSPxjMDVg4r0PA8seduwtfSA3RJ5gA3GcOT35YRRspTgOH0y0NZoIm/Cn7uMU3kshXylfJ4KM+f2cEXmkSE/s+/k8inY9bVZlj16pSbt/YdtNNLC9+h1Beq5Hyj/62jztxpEzde1KQUKvmShyUQJ4/IcRKuSw+iPwWvffYwf6FT7t0+4OIbZLMzA5o0kymjQFBSGTe40ulpbd7XD9BPATJtbDpQXuS1cy/QYGOH7XB/2m5y0K3WV9FnX9MjH67evvB7NLrFplhQ==;20:CSl2X9Iy6ClO8DJZuSlVK7gCuIUzy6z8Ks1WJOT5TsE4/yyhJsOFA1nYXRKxT9oiOK/8i5vKsEFYLg7BHzkkm/UM/b0ao+NQcyQlCnxYuBlyFsL1ict/Q0vwIhkSEsmNtsdnLLLV9dsuz/JDfMuDjoBKiArxBoQJP9jEhB9NCMo= x-ms-office365-filtering-correlation-id: 3de2c9e3-a044-4c4b-9602-08d49d793023 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075);SRVR:BY1PR0401MB1532; wdcipoutbound: EOP-TRUE x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(104084551191319)(146099531331640)(42932892334569); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148);SRVR:BY1PR0401MB1532;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0401MB1532; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39860400002)(39450400003)(39840400002)(39850400002)(377454003)(377424004)(24454002)(13464003)(51444003)(3280700002)(53546009)(2201001)(25786009)(7736002)(122556002)(81166006)(8676002)(66066001)(305945005)(3660700001)(4326008)(6436002)(86362001)(5660300001)(6486002)(77096006)(36756003)(6506006)(345774005)(2906002)(2950100002)(2900100001)(53936002)(6246003)(6512007)(189998001)(50986999)(54356999)(76176999)(8666007)(2501003)(99286003)(54906002)(229853002)(3846002)(102836003)(8936002)(103116003)(6116002)(38730400002)(2421001)(33646002)(72206003)(478600001);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR0401MB1532;H:BY1PR0401MB1532.namprd04.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: MIME-Version: 1.0 X-OriginatorOrg: sandisk.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2017 23:05:18.8603 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0401MB1532 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v4HN5R5D032040 On Tue, 2017-05-16 at 17:31 +0000, Long Li wrote: > > -----Original Message----- > > From: Bart Van Assche [mailto:Bart.VanAssche@sandisk.com] > > Sent: Monday, May 15, 2017 5:01 PM > > To: jejb@linux.vnet.ibm.com; linux-scsi@vger.kernel.org; linux- > > kernel@vger.kernel.org; Long Li ; > > martin.petersen@oracle.com > > Cc: Stephen Hemminger ; KY Srinivasan > > > > Subject: Re: [PATCH] scsi: zero per-cmd driver data for each MQ I/O > > > > On Mon, 2017-05-15 at 23:32 +0000, Long Li wrote: > > > Thanks for looking! Yes this is for chasing a bug. > > > > > > With the patch, we also zero the private data used by lower layer > > > driver, in addition to the private data in scsi_cmnd. > > > > Hello Long, > > > > What bug did you encounter, with which combination of ULP (sd?) and LLD SCSI > > driver(s) and for which request type (REQ_OP_*)? You will have to mention > > that information in the patch description anyway if you want your patch to get > > accepted. > > > > If the bug that you encountered only occurs with a single LLD, would it be > > possible to implement a fix by modifying the LLD instead of the SCSI core? > > The bug I encounter is that in hv_storvsc (a LLD), sometime we are getting stale data in the private driver data memory allocated by SCSI. As a LLD, we expect the memory allocated by SCSI to be zeroed. If not we may send unexpected commands to the device. > > A little background on private data: In LLD's scsi_host_template, the driver may optionally ask SCSI to allocate its private driver memory for each command, by specifying cmd_size. This memory is allocated at the end of scsi_cmnd by SCSI. Later when SCSI queues a command, the LLD can use scsi_cmd_priv to get its private data. > > hv_storvsc doesn't clear its private data before use. I'm not sure about other LLD drivers. Although it's possible to fix it in LLD not SCSI core, I think that is not the ideal place to do it. Whoever is allocating the SCSI command should also zero it. > > There is a similar patch that fixed a similar issue for non-MQ case: > commit ee5242360424b9b967454e9183767323d10cf985 > > I'm sorry I should have put more details in the patch. Hello Long, Thank you for the feedback. I'm working on a patch series that merges the scsi-sq and scsi-mq code paths for command initialization and that should fix the bug you encountered. Bart.