From mboxrd@z Thu Jan 1 00:00:00 1970 From: "hch@lst.de" Subject: Re: [PATCH 1/1] mpt3sas: Ignore unaligned completion length for ZBC_IN Date: Tue, 14 Feb 2017 07:18:26 +0100 Message-ID: <20170214061826.GA10552@lst.de> References: <20170213051152.27741-1-damien.lemoal@wdc.com> <1487012224.2719.3.camel@sandisk.com> <1f98b2ef-89d6-65e4-6424-c3b4b4cf1b82@wdc.com> <1487044768.6475.1.camel@sandisk.com> <1487049066.6475.3.camel@sandisk.com> <6cabab36-3865-1465-fae8-69c437602b80@wdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from verein.lst.de ([213.95.11.211]:48230 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750767AbdBNGS3 (ORCPT ); Tue, 14 Feb 2017 01:18:29 -0500 Content-Disposition: inline In-Reply-To: <6cabab36-3865-1465-fae8-69c437602b80@wdc.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Damien Le Moal Cc: Bart Van Assche , "linux-scsi@vger.kernel.org" , "James.Bottomley@HansenPartnership.com" , "sathya.prakash@broadcom.com" , "chaitra.basappa@broadcom.com" , "martin.petersen@oracle.com" , "suganath-prabu.subramani@broadcom.com" , "hch@lst.de" , "hare@suse.de" , "MPT-FusionLinux.pdl@broadcom.com" On Tue, Feb 14, 2017 at 02:21:37PM +0900, Damien Le Moal wrote: > > I think we want to keep the knowledge of which requests have a request size > > that should be a multiple of the logical block size in the block layer core > > or in the SCSI core but not in the mpt3sas driver. But I'm not sure what the > > best approach is to do that. Should we use the request type, should we add a > > new request attribute or should we add a new function? > > I agree. But the mpt3sas patch that introduced the problem is to solve > problems with a buggy hardware in the first place... A quirck of some > sort. So do we really need such a big change just the report zones > exception ? (all other REQ_TYPE_FS commands either have no payload or > the payload size is LBA aligned) > > Martin, James, Hannes, > > Please advise ! 4.10 is introducing zoned block device support, and from > the first release that will be broken with mpt3sas HBAs if we do not > patch this. Any preferred approach ? I suspect we'll need to move the workaround to the SD driver. While it's an mpt bug, sd is the party that knows which kind of requests were generated, so it's where we can fix up the length in the done callback.