Linux block layer
 help / color / mirror / Atom feed
From: Nilay Shroff <nilay@linux.ibm.com>
To: Daniel Wagner <dwagner@suse.de>,
	Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	Yi Zhang <yi.zhang@redhat.com>
Subject: Re: [PATCH blktests] nvme/052: wait for namespace removal before recreating namespace
Date: Thu, 22 Aug 2024 21:13:29 +0530	[thread overview]
Message-ID: <20a3f01c-0992-45e8-8970-30a2747ed8bf@linux.ibm.com> (raw)
In-Reply-To: <a9a79fc9-6c0b-4a35-afea-85f34e9889bf@flourine.local>



On 8/22/24 20:19, Daniel Wagner wrote:
> On Thu, Aug 22, 2024 at 11:59:35AM GMT, Shinichiro Kawasaki wrote:
>> I can agree with this point: it is odd to suppress errors only for the namespace
>> removal case. I did so to catch other potential errors that _find_nvme_ns() may
>> return in the future for the namespace creation case. But still this way misses
>> other potential errors for the namespace removal case. Maybe I was overthinking.
>> Let's simplify the test with just doing
>>
>>    ns=$(_find_nvme_ns "${uuid}" 2>/dev/null)
>>
>> as you suggest. Still the test case can detect the kernel regression, and I
>> think it's good enough. Will reflect this to v2.
> 
> Not sure if this is relevant, but I'd like to see that we return error
> codes so that the caller can actually decide to ignore the failure or
> not.
The _find_nvme_ns(), when fails to find the relevant namespace, it returns 
"empty string" and if it could find namespace then it returns the namespace 
value to the caller. And then caller (in this case nvmf_wait_for_ns()) would 
take action depending on the return value from _find_nvme_ns().

Thanks,
--Nilay

  reply	other threads:[~2024-08-22 15:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-20 10:20 [PATCH blktests] nvme/052: wait for namespace removal before recreating namespace Shin'ichiro Kawasaki
2024-08-20 16:55 ` Nilay Shroff
2024-08-21  7:21   ` Shinichiro Kawasaki
2024-08-21  9:28     ` Nilay Shroff
2024-08-22  8:33       ` Shinichiro Kawasaki
2024-08-22 11:15         ` Nilay Shroff
2024-08-22 11:59           ` Shinichiro Kawasaki
2024-08-22 14:49             ` Daniel Wagner
2024-08-22 15:43               ` Nilay Shroff [this message]
2024-09-02 10:54                 ` Shinichiro Kawasaki

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=20a3f01c-0992-45e8-8970-30a2747ed8bf@linux.ibm.com \
    --to=nilay@linux.ibm.com \
    --cc=dwagner@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=yi.zhang@redhat.com \
    /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