From: Ming Lei <ming.lei@redhat.com>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"damien.lemoal@opensource.wdc.com"
<damien.lemoal@opensource.wdc.com>,
"johannes.thumshirn@wdc.com" <johannes.thumshirn@wdc.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"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: Mon, 17 Oct 2022 17:50:24 +0800 [thread overview]
Message-ID: <Y00lYIhUNv1CxqiK@T590> (raw)
In-Reply-To: <0af3d1a4-8166-ea1e-8710-c51479c587a1@nvidia.com>
On Mon, Oct 17, 2022 at 09:30:47AM +0000, Chaitanya Kulkarni wrote:
>
> >> + /*
> >> + * 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);
> >> +
> >> + null_destroy_dev(nullb);
> >
> > destroying device is never good cleanup for handling timeout/abort, and it
> > should have been the last straw any time.
> >
>
> That is exactly why I've added the rq_abort_limit, so until the limit
> is not reached null_abort_work() will not get scheduled and device is
> not destroyed.
I meant destroying device should only be done iff the normal abort handler
can't recover the device, however, your patch simply destroys device
without running any abort handling.
Thanks,
Ming
next prev parent reply other threads:[~2022-10-17 9:51 UTC|newest]
Thread overview: 12+ 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 9:25 ` Ming Lei
2022-10-17 9:30 ` Chaitanya Kulkarni
2022-10-17 9:50 ` Ming Lei [this message]
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
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=Y00lYIhUNv1CxqiK@T590 \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=chaitanyak@nvidia.com \
--cc=damien.lemoal@opensource.wdc.com \
--cc=johannes.thumshirn@wdc.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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