From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Tejun Heo <tj@kernel.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org, Dave Jones <dsj@fb.com>, kernel-team@fb.com
Subject: Re: [PATCH] scsi: don't count non-failure CHECK_CONDITION as error
Date: Fri, 15 Jan 2016 07:55:02 -0800 [thread overview]
Message-ID: <1452873302.2356.9.camel@HansenPartnership.com> (raw)
In-Reply-To: <1452872774.2356.5.camel@HansenPartnership.com>
On Fri, 2016-01-15 at 07:46 -0800, James Bottomley wrote:
> On Thu, 2016-01-14 at 16:46 -0500, Tejun Heo wrote:
> > SCSI command completion path bumps ioerr_cnt whenever scsi_cmd
> > ->result isn't zero; unfortunately, this means that non-error sense
> > reporting bumps the counter too. This is pronounced with ATA
> > passthrough commands because most of them explicitly request the
> > resulting taskfile to be transported via sense data bumping the
> > count
> > unconditionally.
> >
> > Don't bump the counter if scsi_cmd->result simply indicates that
> > sense data is available.
> >
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Reported-by: Dave Jones <dsj@fb.com>
> > ---
> > drivers/scsi/scsi_lib.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index fa6b2c4..e90e3f7 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -1622,7 +1622,8 @@ static void scsi_softirq_done(struct request
> > *rq)
> > INIT_LIST_HEAD(&cmd->eh_entry);
> >
> > atomic_inc(&cmd->device->iodone_cnt);
> > - if (cmd->result)
> > + if (cmd->result &&
> > + cmd->result != ((DRIVER_SENSE << 24) |
> > SAM_STAT_CHECK_CONDITION))
> > atomic_inc(&cmd->device->ioerr_cnt);
>
> OK, it makes sense to me that we don't include non-error check
> conditions. However, then you shouldn't be checking DRIVER_SENSE.
> We still have a few drivers that rely on the error handler to fetch
> sense explicitly ... they could eventually return non-error
> conditions as well.
Actually, I take this back: if we add your proposal, we never increment
the ioerr_cnt even for sense returns indicating failure. That looks to
be even worse than incrementing it too often.
The other problem is that if we do this for you, we should do the same
for SCSI with BUSY and QUEUE_FULL ... they indicate temporary retry
conditions and shouldn't be treated as errors.
I'll stop looking now before I find any more problems with the
statistics code ... I think it needs a rethink.
James
next prev parent reply other threads:[~2016-01-15 15:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 21:46 [PATCH] scsi: don't count non-failure CHECK_CONDITION as error Tejun Heo
2016-01-14 21:49 ` [PATCH REPOST] " Tejun Heo
2016-01-15 10:04 ` [PATCH] " Hannes Reinecke
2016-01-15 15:46 ` James Bottomley
2016-01-15 15:55 ` James Bottomley [this message]
2016-01-15 16:50 ` Douglas Gilbert
2016-01-15 18:35 ` James Bottomley
2016-01-15 18:42 ` Tejun Heo
2016-01-15 19:09 ` James Bottomley
2016-01-15 19:27 ` Tejun Heo
2016-01-15 19:36 ` James Bottomley
2016-01-15 19:40 ` Tejun Heo
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=1452873302.2356.9.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=dsj@fb.com \
--cc=kernel-team@fb.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=tj@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.