public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Bart Van Assche <bvanassche@acm.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
	"damien.lemoal@opensource.wdc.com"
	<damien.lemoal@opensource.wdc.com>,
	"johannes.thumshirn@wdc.com" <johannes.thumshirn@wdc.com>,
	"ming.lei@redhat.com" <ming.lei@redhat.com>,
	"shinichiro.kawasaki@wdc.com" <shinichiro.kawasaki@wdc.com>,
	"vincent.fu@samsung.com" <vincent.fu@samsung.com>,
	"yukuai3@huawei.com" <yukuai3@huawei.com>
Subject: Re: [PATCH] null_blk: allow teardown on request timeout
Date: Wed, 2 Nov 2022 01:09:58 +0000	[thread overview]
Message-ID: <0d7bdb05-07e4-d414-dced-8bd30d1fd9c0@nvidia.com> (raw)
In-Reply-To: <b49d7e9b-fdee-915a-436a-bb624addf9a2@acm.org>

On 10/19/22 10:41, Bart Van Assche wrote:
> On 10/18/22 21:19, Chaitanya Kulkarni wrote:
>> Also, I've listed the problem that I've seen first hand for keeping the
>> device in the system that is non-responsive due to request timeouts, in
>> that case we should let user decide whether user wants to remove or keep
>> the device in the system instead of forcing user to keep the device in
>> the system bringing down whole system, and these problems are really
>> hard to debug even with Teledyne LeCroy [1]. This patch follows the same
>> philosophy where user can decide to opt in for removal with module
>> parameter. Once opt-in user knows what he is getting into.
> 
> Hi Chaitanya,
> 
>  From commit f2298c0403b0 ("null_blk: multi queue aware block test 
> driver"): "Written to facilitate testing of the blk-mq code". I'm not 
> sure of this but adding a mechanism like the one in this patch may fall 
> outside the original scope of the null_blk driver.
> 

I did not understand your comment, this patch uses blk_mq_XXX() APIs:-

+	blk_freeze_queue_start(nullb->q);
+	blk_mq_quiesce_queue(nullb->q);
+	/*
+	 * We already ensured that submit_bio() will not add any plugging by
+	 * quiescing so it is safe to sync queue now.
+	 */
+	blk_sync_queue(nullb->q);
+	blk_mq_tagset_busy_iter(nullb->tag_set, null_cancel_request, nullb);
+	blk_mq_tagset_wait_completed_request(nullb->tag_set);
+	/*
+	 * Unblock any pending dispatch I/Os before we destroy the device.
+	 * From null_destroy_dev()->del_gendisk() will set GD_DEAD flag
+	 * causing any new I/O from __bio_queue_enter() to fail with -ENODEV.
+	 */
+	blk_mq_unquiesce_queue(nullb->q);

which are called from error_work issued from blk-mq timeout handler
and that needs to be a part of null_blk so I can submit the testcases
in blktests, these testcases are part of the smoke tests under block
category where block tests needs to be run first to established the
stability of the block layer baseline with minimal driver then moving on 
to complex subsystems of additional driver code.

Calling blk_mq_XXX() APIs from error work issued from block layer
timeout handlers facilitates the testing of the blk-mq code with
combination of different error injection parameters for null_blk with
blk_should_fake_timeout() as posted in the patch test-report.

-ck


      reply	other threads:[~2022-11-02  1:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-16  5:20 [PATCH] null_blk: allow teardown on request timeout Chaitanya Kulkarni
2022-10-17  1:26 ` Damien Le Moal
2022-10-17  8:42   ` Chaitanya Kulkarni
2022-10-17  9:25 ` Ming Lei
2022-10-17  9:30   ` Chaitanya Kulkarni
2022-10-17  9:50     ` Ming Lei
2022-10-17 10:04       ` Chaitanya Kulkarni
2022-10-17 10:16         ` Ming Lei
2022-10-17 10:46           ` Chaitanya Kulkarni
2022-10-17 14:21 ` Bart Van Assche
2022-10-19  4:19   ` Chaitanya Kulkarni
2022-10-19 17:41     ` Bart Van Assche
2022-11-02  1:09       ` Chaitanya Kulkarni [this message]

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=0d7bdb05-07e4-d414-dced-8bd30d1fd9c0@nvidia.com \
    --to=chaitanyak@nvidia.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=johannes.thumshirn@wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=vincent.fu@samsung.com \
    --cc=yukuai3@huawei.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