All of lore.kernel.org
 help / color / mirror / Atom feed
From: "tj@kernel.org" <tj@kernel.org>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"nborisov@suse.com" <nborisov@suse.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>, "shli@fb.com" <shli@fb.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"00moses.alexander00@gmail.com" <00moses.alexander00@gmail.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"joseph.qi@linux.alibaba.com" <joseph.qi@linux.alibaba.com>
Subject: Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release
Date: Wed, 11 Apr 2018 10:30:59 -0700	[thread overview]
Message-ID: <20180411173059.GO793541@devbig577.frc2.facebook.com> (raw)
In-Reply-To: <6cd1d285f726f81186dbab57c3308cc0b257ff99.camel@wdc.com>

Hello,

On Wed, Apr 11, 2018 at 05:26:12PM +0000, Bart Van Assche wrote:
> Please explain what you wrote further. It's not clear to me why you think
> that anything is broken nor what a "sever model" is.

So, sever (or revoke) model is where you actively disconnect an object
and ensuring that there'll be no further references from others.  In
contrast, what we usually do is refcnting, where we don't actively
sever the dying object from its users but let the users drain
themselves over time and destroy the object when we know all the users
are gone (recnt reaching zero).

> I think we really need the blkcg_exit_queue() call in blk_cleanup_queue()
> to avoid race conditions between request queue cleanup and the block cgroup
> controller. Additionally, since it is guaranteed that no new requests will
> be submitted to a queue after it has been marked dead I don't see why it
> would make sense to keep the association between a request queue and the
> blkcg controller until the last reference on a queue is dropped.

Sure, new requests aren't the only source tho.  e.g. there can be
derefs through sysfs / cgroupfs or writeback attempts on dead devices.
If you want to implement sever, you gotta hunt down all those and make
sure they can't make no further derefs.

Thanks.

-- 
tejun

  reply	other threads:[~2018-04-11 17:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-07 10:21 [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release Alexandru Moise
2018-04-09 22:09 ` Tejun Heo
2018-04-11 10:12   ` Alexandru Moise
2018-04-11 14:20     ` Tejun Heo
2018-04-11 14:28       ` Alexandru Moise
2018-04-11 14:46         ` Tejun Heo
2018-04-11 14:51           ` Tejun Heo
2018-04-11 14:56             ` Tejun Heo
2018-04-11 16:42               ` Bart Van Assche
2018-04-11 16:42                 ` Bart Van Assche
2018-04-11 17:00                 ` tj
2018-04-11 17:06                   ` Bart Van Assche
2018-04-11 17:06                     ` Bart Van Assche
2018-04-11 17:15                     ` tj
2018-04-11 17:26                       ` Bart Van Assche
2018-04-11 17:26                         ` Bart Van Assche
2018-04-11 17:30                         ` tj [this message]
2018-04-11 15:54         ` Bart Van Assche
2018-04-11 15:54           ` Bart Van Assche
2018-04-11 19:00           ` Alexandru Moise
2018-04-11 19:55             ` Bart Van Assche
2018-04-11 19:57               ` tj
2018-04-11 20:00                 ` Bart Van Assche
2018-04-11 20:00                   ` Bart Van Assche
2018-04-11 20:02                   ` tj
2018-04-11 20:23                     ` Bart Van Assche
2018-04-11 20:23                       ` Bart Van Assche
2018-04-11 21:23               ` Alexandru Moise
2018-04-11 21:28                 ` Bart Van Assche
2018-04-11 21:28                   ` Bart Van Assche
2018-04-11 22:58                   ` Alexandru Moise

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=20180411173059.GO793541@devbig577.frc2.facebook.com \
    --to=tj@kernel.org \
    --cc=00moses.alexander00@gmail.com \
    --cc=Bart.VanAssche@wdc.com \
    --cc=arnd@arndb.de \
    --cc=axboe@kernel.dk \
    --cc=gregkh@linuxfoundation.org \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=shli@fb.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.