[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y00lYIhUNv1CxqiK@T590>
Date: Mon, 17 Oct 2022 17:50:24 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Chaitanya Kulkarni <chaitanyak@...dia.com>
Cc: "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"damien.lemoal@...nsource.wdc.com" <damien.lemoal@...nsource.wdc.com>,
"johannes.thumshirn@....com" <johannes.thumshirn@....com>,
"bvanassche@....org" <bvanassche@....org>,
"shinichiro.kawasaki@....com" <shinichiro.kawasaki@....com>,
"vincent.fu@...sung.com" <vincent.fu@...sung.com>,
"yukuai3@...wei.com" <yukuai3@...wei.com>
Subject: Re: [PATCH] null_blk: allow teardown on request timeout
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
Powered by blists - more mailing lists