Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nilay Shroff <nilay@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Guixin Liu <kanie@linux.alibaba.com>,
	Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	Sagi Grimberg <sagi@grimberg.me>, Daniel Wagner <dwagner@suse.de>,
	John Garry <john.g.garry@oracle.com>,
	Hannes Reinecke <hare@suse.de>,
	linux-nvme@lists.infradead.org
Subject: Re: [PATCH v2 1/2] nvmet: return Invalid Field for invalid NSIDs in Set Features 82h
Date: Mon, 21 Sep 2026 13:54:38 +0530	[thread overview]
Message-ID: <0834a7d2-dfcf-4c3b-8588-f46dcd42319f@linux.ibm.com> (raw)
In-Reply-To: <20260921065311.GC13667@lst.de>

On 9/21/26 12:23 PM, Christoph Hellwig wrote:
> On Sun, Sep 20, 2026 at 04:37:08PM +0530, Nilay Shroff wrote:
>> On 9/20/26 9:04 AM, Guixin Liu wrote:
>>> diff --git a/drivers/nvme/target/pr.c b/drivers/nvme/target/pr.c
>>> index 0948a690a1c0..a36c732883d4 100644
>>> --- a/drivers/nvme/target/pr.c
>>> +++ b/drivers/nvme/target/pr.c
>>> @@ -51,6 +51,8 @@ u16 nvmet_set_feat_resv_notif_mask(struct nvmet_req *req, u32 mask)
>>>      	if (nsid != U32_MAX) {
>>>    		status = nvmet_req_find_ns(req);
>>> +		if (status == (NVME_SC_INVALID_NS | NVME_STATUS_DNR))
>>> +			return NVME_SC_INVALID_FIELD | NVME_STATUS_DNR;
>>>    		if (status)
>>>    			return status;
>>>    		if (!req->ns->pr.enable)
>>> -- 
>>
>> This looks good to me. However, to avoid hand-coding the same error
>> return code multiple times in the function and to make it a bit more
>> readable, how about modifying it as follows?
> 
> I don't understand how that helps.  If we really want to refactor,
> we could add a version of nvmet_req_find_ns that does it, but
> that feels like a bit of overkill.
> 
I agree that adding a separate helper just for this would be unnecessary.

My suggestion was mainly for readability and to avoid repeating the same
NVME_SC_INVALID_FIELD | NVME_STATUS_DNR error code and keep the error
handling in one place. I also found the two status checks a little
less straightforward to read. When applying the proposed patch, the
resulting code looks like below:

u16 nvmet_get_feat_resv_notif_mask(struct nvmet_req *req)
{
	u16 status;

	status = nvmet_req_find_ns(req);
	if (status == (NVME_SC_INVALID_NS | NVME_STATUS_DNR))
		return NVME_SC_INVALID_FIELD | NVME_STATUS_DNR;
	if (status)
		return status;

	if (!req->ns->pr.enable)
		return NVME_SC_INVALID_FIELD | NVME_STATUS_DNR;

	nvmet_set_result(req, READ_ONCE(req->ns->pr.notify_mask));
	return status;
}

That said, this is mostly a matter of personal preference rather than
a functional concern, so I'm fine with keeping the current version if
everyone agrees.

>> 		if (status == (NVME_SC_INVALID_NS | NVME_STATUS_DNR))
> 
> Still no need for the inner braces here in all versions.
> 
I think Guixin has already replied to this comment in another
email. The inner braces are required here otherwise compiler
would complain:

drivers/nvme/target/pr.c:80:35: error: | has lower precedence than ==; == will be evaluated first [-Werror,-Wparentheses]
    80 |         if (status == NVME_SC_INVALID_NS | NVME_STATUS_DNR)
       |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^


Thanks,
--Nilay



  parent reply	other threads:[~2026-09-21  8:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20  3:34 [PATCH v2 0/2] nvmet: fix FID 82h status codes for invalid NSIDs Guixin Liu
2026-09-20  3:34 ` [PATCH v2 1/2] nvmet: return Invalid Field for invalid NSIDs in Set Features 82h Guixin Liu
2026-09-20 11:07   ` Nilay Shroff
2026-09-21  6:53     ` Christoph Hellwig
2026-09-21  7:56       ` Guixin Liu
2026-09-21  8:24       ` Nilay Shroff [this message]
2026-09-25  7:31   ` Christoph Hellwig
2026-09-25 11:24   ` Nilay Shroff
2026-09-20  3:35 ` [PATCH v2 2/2] nvmet: return Invalid Field for invalid NSIDs in Get " Guixin Liu
2026-09-25  7:32   ` Christoph Hellwig
2026-09-25 11:24   ` Nilay Shroff
2026-10-03  8:54 ` [PATCH v2 0/2] nvmet: fix FID 82h status codes for invalid NSIDs Keith Busch

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=0834a7d2-dfcf-4c3b-8588-f46dcd42319f@linux.ibm.com \
    --to=nilay@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=dwagner@suse.de \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=john.g.garry@oracle.com \
    --cc=kanie@linux.alibaba.com \
    --cc=kbusch@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