[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190319152533.GD24176@localhost.localdomain>
Date: Tue, 19 Mar 2019 09:25:34 -0600
From: Keith Busch <kbusch@...nel.org>
To: Bart Van Assche <bvanassche@....org>
Cc: "jianchao.wang" <jianchao.w.wang@...cle.com>, axboe@...nel.dk,
linux-block@...r.kernel.org, jsmart2021@...il.com,
sagi@...mberg.me, josef@...icpanda.com,
linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
keith.busch@...el.com, hare@...e.de, jthumshirn@...e.de, hch@....de
Subject: Re: [PATCH 0/8]: blk-mq: use static_rqs to iterate busy tags
On Tue, Mar 19, 2019 at 08:10:22AM -0700, Bart Van Assche wrote:
> On Tue, 2019-03-19 at 09:25 +0800, jianchao.wang wrote:
> > Do you mean this patch from Jens ?
> > https://marc.info/?l=linux-block&m=154534605914798&w=2
> >
> > + rcu_read_lock();
> > sbitmap_for_each_set(&bt->sb, bt_iter, &iter_data);
> > + rcu_read_unlock();
> >
> > The busy_iter_fn could sleep for nvme
> > blk_mq_check_expired
> > -> blk_mq_rq_timed_out
> > -> q->mq_ops->timeout
> > nvme_timeout
> > -> nvme_dev_disable
> > -> mutex_lock dev->shutdown_lock
>
> Hi Jianchao,
>
> I think that's an additional reason to rewrite NVMe error handling ...
Nonesense. Block timeout handling runs in a work queue precicesly so
handlers can actually do useful work in line with the notification.
Powered by blists - more mailing lists