All of lore.kernel.org
 help / color / mirror / Atom feed
From: axboe@kernel.dk (Jens Axboe)
Subject: [patch] NVMe: return an error code if blk_mq_alloc_tag_set() fails
Date: Thu, 22 Jan 2015 15:46:23 -0700	[thread overview]
Message-ID: <54C17DBF.40901@kernel.dk> (raw)
In-Reply-To: <alpine.LNX.2.00.1501221626080.15481@localhost.lm.intel.com>

On 01/22/2015 09:48 AM, Keith Busch wrote:
> On Wed, 21 Jan 2015, Jens Axboe wrote:
>> On 01/19/2015 07:43 AM, Dan Carpenter wrote:
>>> In the current code, if blk_mq_alloc_tag_set() fails then it returns
>>> zero (success) instead of preserving the error code.  The caller is not
>>> expecting that and the kernel could be left in an inconsistent state.
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>
>>
>> Looks good to me, Keith, could you ack/review it? Leaving it below...
> 
> Should we bail on the device if tagset allocation fails? If so, the patch
> is good, but I thought it was a concious descision to not return error
> here so the controller can be managed. Capabilities would be limited
> and a failure here probably means there's a bigger problem, so I'm okay
> either way.

That's a good point, you could still send admin IO through the ioctls
even if this fails. Looking at the rest of the function, the error
handling is a bit strange. If we fail the nvme_identify(), we'll just
march on. If the next works, we're good, we return success. But if the
failed one happens to be the last one, we return error.

So we need to clean it up a bit regardless. Question is, what errors
constitute general failure, and which ones we want to allow. If the
rationale is wanting to still access the device and do admin IO, then
none of them should be hard failures. But they should be reported. I can
imagine cases where the device is mostly screwed and you just want to
get the driver loaded successfully to reset/format/fw-update (actually I
don't need to imagine, I've been in those situations!).


-- 
Jens Axboe

  reply	other threads:[~2015-01-22 22:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19 14:43 [patch] NVMe: return an error code if blk_mq_alloc_tag_set() fails Dan Carpenter
2015-01-19 14:43 ` Dan Carpenter
2015-01-22  4:40 ` Jens Axboe
2015-01-22 16:48   ` Keith Busch
2015-01-22 22:46     ` Jens Axboe [this message]
2015-01-22 23:11       ` Keith Busch
2015-01-22 23:15         ` Jens Axboe

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=54C17DBF.40901@kernel.dk \
    --to=axboe@kernel.dk \
    /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.