From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"James.Bottomley@HansenPartnership.com"
<James.Bottomley@HansenPartnership.com>,
"sathya.prakash@broadcom.com" <sathya.prakash@broadcom.com>,
"chaitra.basappa@broadcom.com" <chaitra.basappa@broadcom.com>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"suganath-prabu.subramani@broadcom.com"
<suganath-prabu.subramani@broadcom.com>
Cc: "hch@lst.de" <hch@lst.de>, "hare@suse.de" <hare@suse.de>,
"MPT-FusionLinux.pdl@broadcom.com"
<MPT-FusionLinux.pdl@broadcom.com>
Subject: Re: [PATCH 1/1] mpt3sas: Ignore unaligned completion length for ZBC_IN
Date: Tue, 14 Feb 2017 03:59:43 +0000 [thread overview]
Message-ID: <1487044768.6475.1.camel@sandisk.com> (raw)
In-Reply-To: <1f98b2ef-89d6-65e4-6424-c3b4b4cf1b82@wdc.com>
On Tue, 2017-02-14 at 12:45 +0900, Damien Le Moal wrote:
> On 2/14/17 03:57, Bart Van Assche wrote:
> > On Mon, 2017-02-13 at 14:11 +0900, Damien Le Moal wrote:
> > > The ZBC_IN command (REPORT ZONES) reply length is always a multiple of
> > > 64B and thus may not be aligned on the device LBA size.
> > > For this command, retry due to the unaligned completion length is
> > > incorrect so do not check alignment of the reply length.
> > >
> > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > ---
> > > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > > index 0b5b423..f04b872 100644
> > > --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > > +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> > > @@ -4723,8 +4723,9 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply)
> > > * then scsi-ml does not need to handle this misbehavior.
> > > */
> > > sector_sz = scmd->device->sector_size;
> > > - if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
> > > - xfer_cnt % sector_sz)) {
> > > + if (scmd->request->cmd_type == REQ_TYPE_FS &&
> > > + scmd->cmnd[0] != ZBC_IN &&
> > > + sector_sz && xfer_cnt % sector_sz) {
> > > sdev_printk(KERN_INFO, scmd->device,
> > > "unaligned partial completion avoided (xfer_cnt=%u, sector_sz=%u)\n",
> > > xfer_cnt, sector_sz);
> >
> > What software generated a ZBC_IN request with type REQ_TYPE_FS? Shouldn't
> > all ZBC_IN requests be assigned type REQ_TYPE_BLOCK_PC?
>
> Any application that issues a BLKREPORTZONE ioctl (e.g. mkfs.f2fs or
> libzbc tools) or kernel component calling blkdev_report_zones (e.g.
> f2fs) will generate one or more REQ_OP_ZONE_REPORT BIO which translate
> into a REQ_TYPE_FS requests for the command ZBC_IN. That command does
> not operate on LBAs. The transfer length of the request can be any
> length larger than 64B and the reply length will be at least 64B and
> aligned on a multiple of 64.
>
> The patch "mpt3sas: Force request partial completion alignment" applied
> last week forgot this case, and frankly, I did too despite having looked
> at it.
Hello Damien,
How about modifying the block layer core such that it sets REQ_TYPE_BLOCK_PC
for REQ_OP_ZONE_REPORT requests? Would that be a valid alternative to the
above patch?
Thanks,
Bart.
next prev parent reply other threads:[~2017-02-14 3:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 5:11 [PATCH 1/1] mpt3sas: Ignore unaligned completion length for ZBC_IN Damien Le Moal
2017-02-13 18:57 ` Bart Van Assche
2017-02-14 3:45 ` Damien Le Moal
2017-02-14 3:59 ` Bart Van Assche [this message]
2017-02-14 4:42 ` Damien Le Moal
2017-02-14 5:11 ` Bart Van Assche
2017-02-14 5:21 ` Damien Le Moal
2017-02-14 6:18 ` hch
2017-02-14 6:34 ` Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1487044768.6475.1.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=Damien.LeMoal@wdc.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=MPT-FusionLinux.pdl@broadcom.com \
--cc=chaitra.basappa@broadcom.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sathya.prakash@broadcom.com \
--cc=suganath-prabu.subramani@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.