Message ID | 437f863520874ee386b6882ef749bf8d988839ca.1701540918.git.lduncan@suse.com |
---|---|
State | New |
Headers | show |
Series | scsi: target: iscsi: Fix two protocol issues | expand |
I didn't see any objections to this patch. Are there any issues? On Sat, Dec 2, 2023 at 10:45 AM lduncan@suse.com <lduncan@suse.com> wrote: > > From: Lee Duncan <lduncan@suse.com> > > The LIO target code has a warning about setting the > read and/or write header bits with a PDU that has zero > transfer length, even though the code mentions that the > SPEC (RFC 3720) allows this, and that some initiators > set these bits. But in practice such initiators end up > flooding the logs with thousands of warning messages for > IO that is allowed. > > So change this to a debug message, and clean up the wording > just a little bit while at it. > > Signed-off-by: Lee Duncan <lduncan@suse.com> > Reviewed-by: David Bond <dbond@suse.com> > --- > drivers/target/iscsi/iscsi_target.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c > index f246e5015868..c82dc2cd08b3 100644 > --- a/drivers/target/iscsi/iscsi_target.c > +++ b/drivers/target/iscsi/iscsi_target.c > @@ -1039,9 +1039,10 @@ int iscsit_setup_scsi_cmd(struct iscsit_conn *conn, struct iscsit_cmd *cmd, > hdr->flags &= ~ISCSI_FLAG_CMD_READ; > hdr->flags &= ~ISCSI_FLAG_CMD_WRITE; > > - pr_warn("ISCSI_FLAG_CMD_READ or ISCSI_FLAG_CMD_WRITE" > + pr_debug("ISCSI_FLAG_CMD_READ or ISCSI_FLAG_CMD_WRITE" > " set when Expected Data Transfer Length is 0 for" > - " CDB: 0x%02x, Fixing up flags\n", hdr->cdb[0]); > + " CDB: 0x%02x, cleared READ/WRITE flag(s)\n", > + hdr->cdb[0]); > } > > if (!(hdr->flags & ISCSI_FLAG_CMD_READ) && > -- > 2.43.0 >
On 12/7/23 11:42 AM, lduncan@suse.com wrote: > From: Lee Duncan <lduncan@suse.com> > > The LIO target code has a warning about setting the > read and/or write header bits with a PDU that has zero > transfer length, even though the code mentions that the > SPEC (RFC 3720) allows this, and that some initiators > set these bits. But in practice such initiators end up > flooding the logs with thousands of warning messages for > IO that is allowed. > I've never seen us hit this. What initiator is doing this and what is the command they are sending? Is it also related to the first patch? Is some initiator sending something like a TUR with the immediate bit set during some sort of stall/timeout?
diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c index f246e5015868..c82dc2cd08b3 100644 --- a/drivers/target/iscsi/iscsi_target.c +++ b/drivers/target/iscsi/iscsi_target.c @@ -1039,9 +1039,10 @@ int iscsit_setup_scsi_cmd(struct iscsit_conn *conn, struct iscsit_cmd *cmd, hdr->flags &= ~ISCSI_FLAG_CMD_READ; hdr->flags &= ~ISCSI_FLAG_CMD_WRITE; - pr_warn("ISCSI_FLAG_CMD_READ or ISCSI_FLAG_CMD_WRITE" + pr_debug("ISCSI_FLAG_CMD_READ or ISCSI_FLAG_CMD_WRITE" " set when Expected Data Transfer Length is 0 for" - " CDB: 0x%02x, Fixing up flags\n", hdr->cdb[0]); + " CDB: 0x%02x, cleared READ/WRITE flag(s)\n", + hdr->cdb[0]); } if (!(hdr->flags & ISCSI_FLAG_CMD_READ) &&