From: Ziyang Zhang <ZiyangZhang@linux.alibaba.com>
To: Ming Lei <ming.lei@redhat.com>
Cc: linux-block@vger.kernel.org, Christoph Hellwig <hch@infradead.org>
Subject: Re: use of the system work queue in ublk
Date: Mon, 18 Jul 2022 16:55:57 +0800 [thread overview]
Message-ID: <bcd9ac30-9961-5607-e40d-41915af5cd88@linux.alibaba.com> (raw)
In-Reply-To: <YtUNX2l2xkWXQwYA@T590>
On 2022/7/18 15:35, Ming Lei wrote:
> Hi Christoph,
>
> On Sun, Jul 17, 2022 at 11:38:25PM -0700, Christoph Hellwig wrote:
>> Hi Ming,
>>
>> it seems like ublk uses schedule_work to stop the device, which
>> includes a del_gendisk. I'm a little fearful this will gets us into
>> lockdep chains of death once syzbot or Tetsu notice it.
>
> ublksrv has two built-in tests(generic/001, generic/002) for covering
> heavy io with device removal and killing ubq_daemon, not see lockdep
> warning when running the two tests with lockdep enabled.
>
> Could you or Tetsu provide a bit more info about the warning?
>
>>
>> That being said, I don't reall understand the design of
>> ublk_daemon_monitor_work, which is only used to kick off other
>> work to start with.
>
> If the ubq daemon becomes dead, ublk_daemon_monitor_work will be
> scheduled for handling the error: abort pending io requests, and
> start to delete disk.
>
> It has to be triggered when del_gendisk() is in-progress for making
> forward progress.
>
>
> Thanks,
> Ming
Hi Ming,
Just to make sure I understand usage of ublk_daemon_monitor_work correctly.
1) For a dying ubq daemon, ublk_daemon_monitor_work schedule stop work first.
2) The stop work calls del_gendisk() and it is blocked because there are
pending blk-mq requests(maybe handling in ublksrv target).
3) Meanwhile, the monitor work aborts all pending blk-mq IOs
(with UBLK_IO_FLAG_ACTIVE unset) by blk_mq_end_request(req, BLK_STS_IOERR).
4) After all pending blk-mq reqs are aborted,
del_gendisk() in stop work returns and /dev/ublkbX is removed.
No more blk-mq reqs.
5) In stop work, cancel all queued(with UBLK_IO_FLAG_ACTIVE set) ublk IOs
by io_uring_cmd_done(io->cmd, UBLK_IO_RES_ABORT, 0) and ublksrv won't
issue sqes again.
Hope I am correct and all of these works looks good to me.
Besides, the tests(generic/001, generic/002) run successfully for me.
Regards,
Ziyang Zhang
prev parent reply other threads:[~2022-07-18 8:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 6:38 use of the system work queue in ublk Christoph Hellwig
2022-07-18 7:35 ` Ming Lei
2022-07-18 8:55 ` Ziyang Zhang [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=bcd9ac30-9961-5607-e40d-41915af5cd88@linux.alibaba.com \
--to=ziyangzhang@linux.alibaba.com \
--cc=hch@infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.