From: Ewan Milne <emilne@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH RFC 1/9] [SCSI] Detect overflow of sense data buffer
Date: Tue, 22 Jan 2013 10:08:43 -0500 [thread overview]
Message-ID: <1358867323.4420.315.camel@localhost.localdomain> (raw)
In-Reply-To: <1358527592.2345.35.camel@dabdike.int.hansenpartnership.com>
On Fri, 2013-01-18 at 16:46 +0000, James Bottomley wrote:
> On Fri, 2013-01-18 at 11:27 -0500, Ewan D. Milne wrote:
> > --- a/drivers/scsi/scsi_error.c
> > +++ b/drivers/scsi/scsi_error.c
> > @@ -241,6 +241,9 @@ static int scsi_check_sense(struct scsi_cmnd *scmd)
> > if (! scsi_command_normalize_sense(scmd, &sshdr))
> > return FAILED; /* no valid sense data */
> >
> > + if (sshdr.overflow)
> > + scmd_printk(KERN_WARNING, scmd, "Sense data overflow");
> > +
> > if (scsi_sense_is_deferred(&sshdr))
> > return NEEDS_RETRY;
> >
> > @@ -2059,14 +2062,18 @@ int scsi_normalize_sense(const u8 *sense_buffer, int sb_len,
> > sshdr->asc = sense_buffer[2];
> > if (sb_len > 3)
> > sshdr->ascq = sense_buffer[3];
> > + if (sb_len > 4)
> > + sshdr->overflow = ((sense_buffer[4] & 0x80) != 0);
> > if (sb_len > 7)
> > sshdr->additional_length = sense_buffer[7];
> > } else {
> > /*
> > * fixed format
> > */
> > - if (sb_len > 2)
> > + if (sb_len > 2) {
> > + sshdr->overflow = ((sense_buffer[2] & 0x10) != 0);
> > sshdr->sense_key = (sense_buffer[2] & 0xf);
> > + }
> > if (sb_len > 7) {
> > sb_len = (sb_len < (sense_buffer[7] + 8)) ?
> > sb_len : (sense_buffer[7] + 8);
>
> This isn't the right way to do it: The overflow bit is a recent
> introduction in SPC-4. The correct way to tell if we have an overflow
> or not is to look at the additional sense length and compare it to the
> allocation length; this will work for everything.
Unfortunately, I am not sure that the allocation length that was sent
to the device is always available. I will look into this more closely
but it appeared to me that e.g. FC drivers like qla2xxx get the sense
data automatically from the HBA firmware. In the case of that driver
the host sense buffer size looks like it is hard-coded to 32 bytes,
for all I know the firmware might only asking for 18 bytes.
Of course, for a normal REQUEST SENSE command where the allocation
length is in the CDB, it would indeed be easy to add a check against
the additional sense length.
>
> I'm not even convinced that overflow is important: for a lot of the
> sense probes, we deliberately induce overflows by giving the request
> sense command a short buffer. Printing a warning in scsi_check_sense
> will get very noisy very fast.
That would indeed be a problem. I didn't see this behavior when testing
the changes but I'll need to investigate this further.
The purpose of detecting the sense data overflow was to provide some
visibility that a device is returning a large amount of sense data that
is currently being silently ignored. In the case of descriptor format
sense data, it is possible that a descriptor we want to examine is
located after one or more other descriptors, and we might not get it
at all if the buffer isn't large enough.
>
> James
Thanks for your comments.
>
>
next prev parent reply other threads:[~2013-01-22 15:08 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 16:27 [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling Ewan D. Milne
2013-01-18 16:27 ` [PATCH RFC 1/9] [SCSI] Detect overflow of sense data buffer Ewan D. Milne
2013-01-18 16:46 ` James Bottomley
2013-01-21 7:26 ` Hannes Reinecke
2013-01-21 8:58 ` James Bottomley
2013-01-21 17:42 ` Douglas Gilbert
2013-01-22 15:10 ` Ewan Milne
2013-01-23 7:16 ` Hannes Reinecke
2013-01-22 15:08 ` Ewan Milne [this message]
2013-01-23 10:44 ` Hannes Reinecke
2013-01-23 13:06 ` James Bottomley
2013-01-23 21:21 ` Ewan Milne
2013-01-18 16:27 ` [PATCH RFC 2/9] [SCSI] Generate uevent on sd capacity change Ewan D. Milne
2013-01-18 16:27 ` [PATCH RFC 3/9] [SCSI] Add a kernel config option for enhanced Unit Attention support Ewan D. Milne
2013-01-18 16:27 ` [PATCH RFC 4/9] [SCSI] Rename scsi_evt_xxx to sdev_evt_xxx and scsi_event to sdev_event Ewan D. Milne
2013-01-22 17:33 ` Bart Van Assche
2013-01-23 21:08 ` Ewan Milne
2013-01-22 17:38 ` Bart Van Assche
2013-01-23 20:39 ` Ewan Milne
2013-01-18 16:27 ` [PATCH RFC 5/9] [SCSI] Add support for scsi_target events Ewan D. Milne
2013-01-18 16:27 ` [PATCH RFC 6/9] [SCSI] Generate uevents for certain Unit Attention codes Ewan D. Milne
2013-01-18 16:27 ` [PATCH RFC 7/9] [SCSI] Add sysfs support for enhanced Unit Attention handling Ewan D. Milne
2013-01-18 16:27 ` [PATCH RFC 8/9] [SCSI] Add sense and Unit Attention generation to scsi_debug Ewan D. Milne
2013-01-19 18:43 ` Douglas Gilbert
2013-01-22 15:12 ` Ewan Milne
2013-01-18 16:27 ` [PATCH RFC 9/9] [SCSI] Streamline detection of FM/EOM/ILI status Ewan D. Milne
2013-01-24 0:19 ` [PATCH RFC 0/9] [SCSI] Enhanced sense and Unit Attention handling Bart Van Assche
2013-01-24 11:38 ` Hannes Reinecke
2013-01-24 14:00 ` Ewan Milne
2013-01-24 14:01 ` Mike Christie
2013-01-24 22:02 ` Ewan Milne
2013-01-24 22:47 ` Mike Christie
2013-01-24 14:38 ` Bart Van Assche
2013-01-24 14:51 ` Hannes Reinecke
2013-01-24 15:00 ` Mike Christie
2013-01-24 15:15 ` Hannes Reinecke
2013-01-24 22:00 ` Ewan Milne
2013-01-26 18:20 ` Mike Christie
2013-01-28 6:56 ` Hannes Reinecke
2013-01-28 15:05 ` Jeremy Linton
2013-01-28 15:44 ` Bart Van Assche
2013-01-28 15:48 ` Hannes Reinecke
2013-01-28 20:26 ` James Bottomley
2013-01-28 15:52 ` Jeremy Linton
2013-01-28 16:04 ` Ewan Milne
2013-01-28 16:18 ` Mike Christie
2013-01-29 5:01 ` Shyam_Iyer
2013-01-24 13:53 ` Ewan Milne
2013-01-31 16:27 ` Ewan Milne
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=1358867323.4420.315.camel@localhost.localdomain \
--to=emilne@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).