From: Christoph Hellwig <hch@lst.de>
To: Chao Leng <lengchao@huawei.com>
Cc: Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
kbusch@kernel.org, axboe@fb.com, hch@lst.de
Subject: Re: [PATCH 3/3] nvme-core: fix crash when nvme_enable_aen timeout
Date: Fri, 21 Aug 2020 09:49:10 +0200 [thread overview]
Message-ID: <20200821074910.GA30216@lst.de> (raw)
In-Reply-To: <820d5867-3e44-a009-d6b5-ea1a3fecd037@huawei.com>
On Thu, Aug 20, 2020 at 02:43:20PM +0800, Chao Leng wrote:
>>> -static void nvme_enable_aen(struct nvme_ctrl *ctrl)
>>> +static int nvme_enable_aen(struct nvme_ctrl *ctrl)
>>> {
>>> u32 result, supported_aens = ctrl->oaes & NVME_AEN_SUPPORTED;
>>> int status;
>>> if (!supported_aens)
>>> - return;
>>> + return 0;
>>> status = nvme_set_features(ctrl, NVME_FEAT_ASYNC_EVENT, supported_aens,
>>> NULL, 0, &result);
>>> - if (status)
>>> + if (status) {
>>> dev_warn(ctrl->device, "Failed to configure AEN (cfg %x)\n",
>>> supported_aens);
>>> + if (status < 0)
>>> + return status;
>>
>> Why do you need to check status < 0, you need to fail it regardless.
>
> agree.
> Just want to keep the old logic. I guess the old logic: if supported_aens
> is true, the result of set features can ignore.
>
> If there is no objection to doing so, I will resend the patch later.
In the past we've dedice to ignore real NVMe errors in various
spots as the functionality wasn't deemed critical. I think that is
pretty sloppy and we should only do that where we really have to.
next prev parent reply other threads:[~2020-08-21 7:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-20 3:54 [PATCH 3/3] nvme-core: fix crash when nvme_enable_aen timeout Chao Leng
2020-08-20 4:30 ` Sagi Grimberg
2020-08-20 6:43 ` Chao Leng
2020-08-21 7:49 ` Christoph Hellwig [this message]
2020-08-21 20:17 ` Sagi Grimberg
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=20200821074910.GA30216@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=kbusch@kernel.org \
--cc=lengchao@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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