From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Nilay Shroff <nilay@linux.ibm.com>,
Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
hch <hch@lst.de>, "kbusch@kernel.org" <kbusch@kernel.org>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"gjoyce@linux.ibm.com" <gjoyce@linux.ibm.com>
Subject: Re: [PATCH blktests 0/2] add nvme test for creating sleep while atomic kernel BUG
Date: Tue, 3 Dec 2024 08:26:47 +0000 [thread overview]
Message-ID: <77fc8b7a-4d90-4496-bce6-94f3af5c70df@nvidia.com> (raw)
In-Reply-To: <9d6b3b9c-c9df-4fcd-bf2e-6a5635171bcd@linux.ibm.com>
On 12/2/24 21:38, Nilay Shroff wrote:
> Hitting the kernel BUG depends on the race. In the test case, we disable the target ns
> and then write to it and there's a time window between "disabling ns and writing to it".
> During this time window, after disabling ns but before we actually begin writing to it,
> if the target could clean up ns and remove it from subsystem Xarray then we may not hit
> this BUG. So I run the test case in a loop for 10 times hoping that we'd hit it at-least
> once. However, on my test system, I could hit it 2-3 times for each run of the test.
Thanks for the explanation, however we need a test that will hit the bug
100% of the
time and will avoid different behavior when users run it multiple times.
Luis has shared his general experience running block test and conclusion
was we need to
have tests that are consistent and not have different results when
executed multiple
times. From the feedback we got we can't really guarantee that every
user will know
this and or adjust the testcase running loop to hit the bug and run it
for multiple
times, that brings down effectiveness of the test. Not only that it also
becomes real
problem when to build a CI on the top of blktest.
How about we add an error injection code so it will prolong the race
window in such
a way it will stop the target from cleaning up the namespace and
removing it from
xarray when disable ns command is executed and then writing to it ?
of-course
before disabling the ns we will have to enable the corresponding error
injection code
potentially sleep.
This is guarantee that we will his the race window and make the test
effective 100%
of the time.
Or there any other simple solution we can think of ?
-ck
next prev parent reply other threads:[~2024-12-03 8:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 8:01 [PATCH blktests 0/2] add nvme test for creating sleep while atomic kernel BUG Nilay Shroff
2024-11-29 8:01 ` [PATCH blktests 1/2] nvme/052: move nvmf_wait_for_ns() to common/nvme Nilay Shroff
2024-12-03 4:18 ` Chaitanya Kulkarni
2024-11-29 8:01 ` [PATCH blktests 2/2] nvme: add test for writing to file-ns just after disabling it Nilay Shroff
2024-11-30 9:10 ` [PATCH blktests 0/2] add nvme test for creating sleep while atomic kernel BUG Shinichiro Kawasaki
2024-12-03 4:20 ` Chaitanya Kulkarni
2024-12-03 5:38 ` Nilay Shroff
2024-12-03 8:26 ` Shinichiro Kawasaki
2024-12-03 9:05 ` Nilay Shroff
2024-12-06 1:09 ` Shinichiro Kawasaki
2024-12-03 8:26 ` Chaitanya Kulkarni [this message]
2024-12-04 10:08 ` Nilay Shroff
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=77fc8b7a-4d90-4496-bce6-94f3af5c70df@nvidia.com \
--to=chaitanyak@nvidia.com \
--cc=axboe@kernel.dk \
--cc=gjoyce@linux.ibm.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--cc=sagi@grimberg.me \
--cc=shinichiro.kawasaki@wdc.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