linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ewan Milne <emilne@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH RFC 1/9] [SCSI] Detect overflow of sense data buffer
Date: Tue, 22 Jan 2013 10:10:46 -0500	[thread overview]
Message-ID: <1358867446.4420.317.camel@localhost.localdomain> (raw)
In-Reply-To: <50FCEDB4.8080801@suse.de>

On Mon, 2013-01-21 at 08:26 +0100, Hannes Reinecke wrote:
> On 01/18/2013 05:46 PM, 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.
> >
> > 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.
> >
> And indeed I would rather prefer to have it the other way round;
> we're using a fixed sense_buffer within the SCSI stack, which might
> not be large enough to hold all sense data.
> So I would prefer to have an indicator on whether _the internal_ 
> sense buffer overflowed; this would even give us some valid use-case 
> now.

So, if I understand what you're saying, we could check for overflow if
(sense_data[7] + 8) > SCSI_SENSE_BUFFERSIZE

We could do that, certainly.  I think, though, that overflow of sense
data is more likely to occur if a sense buffer smaller than
SCSI_SENSE_BUFFERSIZE bytes is used, e.g. by a call to
scsi_eh_prep_cmnd(), which is an exported symbol.

The existing 96-byte SCSI_SENSE_BUFFERSIZE may well be big enough.
(I did increase it to the SPC-4 defined value of 252 bytes in a later
patch in the series if the appropriate kernel config option is enabled.)

> Plus we can add the sense buffer overflow bit to that if required.
> 
> Cheers,
> 
> Hannes

Thanks for your comments.



  parent reply	other threads:[~2013-01-22 15:11 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 [this message]
2013-01-23  7:16         ` Hannes Reinecke
2013-01-22 15:08     ` Ewan Milne
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=1358867446.4420.317.camel@localhost.localdomain \
    --to=emilne@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=hare@suse.de \
    --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).