From: Christoph Hellwig <hch@lst.de>
To: Ming Lei <ming.lei@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
axboe@kernel.dk, linux-block@vger.kernel.org
Subject: Re: [PATCH 2/2] Revert "ublk_drv: fix request queue leak"
Date: Wed, 20 Jul 2022 08:07:05 +0200 [thread overview]
Message-ID: <20220720060705.GB6734@lst.de> (raw)
In-Reply-To: <YtalgzqC/q3JpYCR@T590>
On Tue, Jul 19, 2022 at 08:37:23PM +0800, Ming Lei wrote:
> This change will break START_DEV/STOP_DEV, which is supposed to run
> multiple cycles after the device is added, especially this way can
> help to implement error recovery from userside, such as one ubq_daemon
> is crashed/hang, the device can be recovered by sending STOP_DEV/START_DEV
> commands again after new ubq_daemon is setup.
What is broken in START_DEV/STOP_DEV? Please explain the semantics you
want and what doesn't work. FYI, there is nothing in the test suite the
complains. And besides the obvious block layer bug that Jens found you
seemed to be perfectly happy with the semantics.
> So here we do need separated request_queue/disk, and the model is
> similar with scsi's, in which disk rebind needs to be supported
> and GD_OWNS_QUEUE can't be set.
SCSI needs it because it needs the request_queue to probe for what ULP
to bind to, and it allows to unbind the ULP. None of that is the case
here. And managing the lifetimes separately is a complete mess, so
don't do it. Especially not in a virtual driver where you don't have
to cater to a long set protocol like SCSI.
>
> Thanks,
> Ming
---end quoted text---
next prev parent reply other threads:[~2022-07-20 6:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 6:29 [PATCH 1/2] block: call blk_mq_exit_queue from disk_release for never added disks Christoph Hellwig
2022-07-18 6:29 ` [PATCH 2/2] Revert "ublk_drv: fix request queue leak" Christoph Hellwig
2022-07-19 12:37 ` Ming Lei
2022-07-20 6:07 ` Christoph Hellwig [this message]
2022-07-20 7:47 ` Ming Lei
2022-07-20 9:00 ` Christoph Hellwig
2022-07-20 10:16 ` Ming Lei
2022-07-20 10:23 ` Ming Lei
2022-07-20 13:08 ` Christoph Hellwig
2022-07-20 15:33 ` Ming Lei
2022-07-21 5:12 ` Christoph Hellwig
2022-07-18 7:18 ` [PATCH 1/2] block: call blk_mq_exit_queue from disk_release for never added disks Ming Lei
2022-07-18 8:33 ` Ming Lei
2022-07-18 13:08 ` Christoph Hellwig
2022-07-18 13:07 ` Christoph Hellwig
2022-07-18 15:16 ` Ming Lei
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=20220720060705.GB6734@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).