From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "nab@linux-iscsi.org" <nab@linux-iscsi.org>
Cc: "hch@lst.de" <hch@lst.de>, "ddiss@suse.de" <ddiss@suse.de>,
"hare@suse.com" <hare@suse.com>,
"target-devel@vger.kernel.org" <target-devel@vger.kernel.org>,
"agrover@redhat.com" <agrover@redhat.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH 04/33] target: Fix BYTCHK=0 handling for VERIFY and WRITE AND VERIFY commands
Date: Mon, 5 Jun 2017 16:49:50 +0000 [thread overview]
Message-ID: <1496681389.2623.11.camel@sandisk.com> (raw)
In-Reply-To: <1496467944.27407.299.camel@haakon3.risingtidesystems.com>
On Fri, 2017-06-02 at 22:32 -0700, Nicholas A. Bellinger wrote:
> On Fri, 2017-06-02 at 16:52 +0000, Bart Van Assche wrote:
> > In this patch series I have addressed all comments that made sense to me. Sorry
> > if you feel offended because I had not addressed the two comments you referred to
> > above. The reason I had not addressed these comments is because these comments
> > are wrong in my opinion. Hence, please reconsider this patch.
>
> Nope. Here are the details again.
>
> First, it drops setting SCF_SCSI_DATA_CDB for WRITE_VERIFY in all cases,
> and only sets it for BYTCHK=0.
>
> Yes, I understand the spec says hosts are not supposed to send a payload
> when BYTCHK=0, but that doesn't stop some from trying.
>
> Any CDB that can potentially allocate SGLS via target_alloc_sgl() must
> set this flag. No other CDBs set SCF_SCSI_DATA_CDB based on bits in the
> CDB, and *_VERIFY is no exception.
A quote from the SBC-4 section about VERIFY(10): "If the byte check (BYTCHK)
field is set to 00b, then no Data-Out Buffer transfer shall occur". In other
words, if a VERIFY or WRITE VERIFY command is received with BYTCHK=0,
transferring the Data-Out buffer is not only superfluous it is also against
the SCSI specs. Today target_cmd_size_check() terminates SCSI commands for
which the size of the Data-Out buffer exceeds the expected size with
TCM_INVALID_CDB_FIELD so the data transfer doesn't happen anyway. Hence it
is not necessary to allocate an SGL with target_alloc_sgl() if BYTCHK=0.
> Secondly, the force setting of size in sbc_parse_verify(), instead of
> what was actually received over the write is totally wrong. Like I said
> before, the size in sbc_parse_cdb() is what's extracted from the CDB
> transfer length, and not what the spec says the correct size should be.
Please take the SCSI specs seriously instead of ignoring the SCSI specs. I
think for VERIFY and WRITE VERIFY with BYTCHK=0, the size extracted from the
CDB should be zero bytes.
What's needed in my opinion to make VERIFY and WRITE VERIFY processing
compliant with the SCSI specs is the following:
- Patch 04/33 from this series that fixes the parsing of these commands.
- Patch 25/33 from this series that fixes handling of too large Data-Out
buffers for the iSCSI target driver (the qla2xxx and ib_srpt target drivers
already handle this case correctly).
- Patch 30/33 from this series that makes target_cmd_size_check() send the
correct sense code to the initiator system for too large Data-Out buffers.
Bart.
next prev parent reply other threads:[~2017-06-05 16:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170523234854.21452-1-bart.vanassche@sandisk.com>
2017-05-23 23:48 ` [PATCH 04/33] target: Fix BYTCHK=0 handling for VERIFY and WRITE AND VERIFY commands Bart Van Assche
2017-06-02 4:15 ` Nicholas A. Bellinger
2017-06-02 16:52 ` Bart Van Assche
2017-06-03 5:32 ` Nicholas A. Bellinger
2017-06-03 5:37 ` Nicholas A. Bellinger
2017-06-05 16:49 ` Bart Van Assche [this message]
2017-06-05 22:32 ` David Butterfield
2017-06-05 23:17 ` Bart Van Assche
2017-05-23 23:48 ` [PATCH 08/33] target: Fix a deadlock between the XCOPY code and iSCSI session shutdown Bart Van Assche
2017-06-02 4:35 ` Nicholas A. Bellinger
2017-05-23 23:48 ` [PATCH 09/33] configfs: Introduce config_item_get_unless_zero() Bart Van Assche
2017-05-28 9:33 ` Christoph Hellwig
2017-05-28 16:37 ` Bart Van Assche
2017-06-13 23:22 ` Mike Christie
2017-05-23 23:48 ` [PATCH 15/33] xen/scsiback: Fix a use-after-free Bart Van Assche
2017-05-23 23:48 ` [PATCH 16/33] xen/scsiback: Replace a waitqueue and a counter by a completion Bart Van Assche
2017-05-23 23:48 ` [PATCH 17/33] xen/scsiback: Make TMF processing slightly faster Bart Van Assche
2017-05-23 23:48 ` [PATCH 25/33] target/iscsi: Avoid overflowing the receive buffer Bart Van Assche
2017-05-23 23:48 ` [PATCH 29/33] target/iscsi: Simplify timer manipulation code Bart Van Assche
[not found] ` <20170523234854.21452-16-bart.vanassche@sandisk.com>
2017-05-26 9:57 ` [PATCH 15/33] xen/scsiback: Fix a use-after-free Juergen Gross
2017-06-03 5:40 ` Nicholas A. Bellinger
[not found] ` <1496468455.27407.305.camel@haakon3.risingtidesystems.com>
2017-06-03 7:04 ` Nicholas A. Bellinger
[not found] ` <1496473471.27407.317.camel@haakon3.risingtidesystems.com>
2017-06-03 7:06 ` Juergen Gross
[not found] ` <20170523234854.21452-17-bart.vanassche@sandisk.com>
2017-05-26 10:13 ` [PATCH 16/33] xen/scsiback: Replace a waitqueue and a counter by a completion Juergen Gross
2017-06-03 5:41 ` Nicholas A. Bellinger
[not found] ` <20170523234854.21452-18-bart.vanassche@sandisk.com>
2017-05-26 10:18 ` [PATCH 17/33] xen/scsiback: Make TMF processing slightly faster Juergen Gross
2017-06-03 5:41 ` Nicholas A. Bellinger
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=1496681389.2623.11.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=agrover@redhat.com \
--cc=ddiss@suse.de \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=nab@linux-iscsi.org \
--cc=stable@vger.kernel.org \
--cc=target-devel@vger.kernel.org \
/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.