linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "tj@kernel.org" <tj@kernel.org>
To: "hch@lst.de" <hch@lst.de>
Cc: Bart Van Assche <Bart.VanAssche@wdc.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"00moses.alexander00@gmail.com" <00moses.alexander00@gmail.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH] block: Ensure that a request queue is dissociated from the cgroup controller
Date: Thu, 12 Apr 2018 06:48:12 -0700	[thread overview]
Message-ID: <20180412134812.GW793541@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <20180412131440.GA5476@lst.de>

Hello,

On Thu, Apr 12, 2018 at 03:14:40PM +0200, hch@lst.de wrote:
> > At least the SCSI ULP drivers drop the last reference to a disk after
> > the blk_cleanup_queue() call. As explained in the description of commit
> > a063057d7c73, removing a request queue from blkcg must happen before
> > blk_cleanup_queue() finishes because a block driver may free the
> > request queue spinlock immediately after blk_cleanup_queue() returns.
> > So I don't think that we can move the code that removes a request
> > queue from blkcg into put_disk(). Another challenge is that some block
> > drivers (e.g. skd) clear the disk->queue pointer if device_add_disk()
> > has not been called to avoid that put_disk() causes a request queue
> > reference count imbalance.
> 
> Which sounds like a very good reason not to use a driver controller
> lock for internals like blkcq.
> 
> In fact splitting the lock used for synchronizing access to queue
> fields from the driver controller lock used to synchronize I/O
> in the legacy path in long overdue.

It'd be probably a lot easier to make sure the shared lock doesn't go
away till all the request_queues using it go away.  The choice is
between refcnting something which carries the lock and double locking
in hot paths.  Can't think of many downsides of the former approach.

Thanks.

-- 
tejun

  reply	other threads:[~2018-04-12 13:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12  1:58 [PATCH] block: Ensure that a request queue is dissociated from the cgroup controller Bart Van Assche
2018-04-12  4:20 ` Alexandru Moise
2018-04-12  4:32   ` Alexandru Moise
2018-04-12  4:22 ` Alexandru Moise
2018-04-12  5:34 ` Christoph Hellwig
2018-04-12 11:52   ` Bart Van Assche
2018-04-12 13:14     ` hch
2018-04-12 13:48       ` tj [this message]
2018-04-12 13:56         ` hch
2018-04-12 13:58           ` tj
2018-04-12 14:07             ` tj
2018-04-12 13:51 ` Tejun Heo
2018-04-12 14:09   ` Bart Van Assche
2018-04-12 15:37     ` Tejun Heo
2018-04-12 16:03       ` Bart Van Assche
2018-04-12 16:12         ` tj
2018-04-12 16:29           ` Bart Van Assche
2018-04-12 18:11             ` tj
2018-04-12 18:56               ` Bart Van Assche
2018-04-12 19:09                 ` tj
2018-04-12 22:40                   ` Bart Van Assche
2018-04-13 15:18                     ` tj

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=20180412134812.GW793541@devbig577.frc2.facebook.com \
    --to=tj@kernel.org \
    --cc=00moses.alexander00@gmail.com \
    --cc=Bart.VanAssche@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    /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).