[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f9527dc23ae63e4a58e3fabda0320c8bce7714ae.camel@wdc.com>
Date: Wed, 11 Apr 2018 20:23:05 +0000
From: Bart Van Assche <Bart.VanAssche@....com>
To: "tj@...nel.org" <tj@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"nborisov@...e.com" <nborisov@...e.com>,
"axboe@...nel.dk" <axboe@...nel.dk>, "shli@...com" <shli@...com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"00moses.alexander00@...il.com" <00moses.alexander00@...il.com>,
"joseph.qi@...ux.alibaba.com" <joseph.qi@...ux.alibaba.com>,
"arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue
release
On Wed, 2018-04-11 at 13:02 -0700, tj@...nel.org wrote:
> On Wed, Apr 11, 2018 at 08:00:29PM +0000, Bart Van Assche wrote:
> > On Wed, 2018-04-11 at 12:57 -0700, tj@...nel.org wrote:
> > > On Wed, Apr 11, 2018 at 01:55:25PM -0600, Bart Van Assche wrote:
> > > > On 04/11/18 13:00, Alexandru Moise wrote:
> > > > > But the root cause of it is in blkcg_init_queue() when blkg_create() returns
> > > > > an ERR ptr, because it tries to insert into a populated index into blkcg->blkg_tree,
> > > > > the entry that we fail to remove at __blk_release_queue().
> > > >
> > > > Hello Alex,
> > > >
> > > > Had you considered something like the untested patch below?
> > >
> > > But queue init shouldn't fail here, right?
> >
> > Hello Tejun,
> >
> > Your question is not entirely clear to me. Are you referring to the atomic
> > allocations in blkg_create() or are you perhaps referring to something else?
>
> Hmm.. maybe I'm confused but I thought that the fact that
> blkcg_init_queue() fails itself is already a bug, which happens
> because a previously destroyed queue left behind blkgs.
Hello Tejun,
I had missed the start of this thread so I was not aware of which problem Alex
was trying to solve. In the description of v1 of this patch I read that Alex
thinks that he ran into a scenario in which blk_queue_alloc_node() assigns a
q->id that is still in use by another request queue? That's weird. The following
code still occurs in __blk_release_queue():
ida_simple_remove(&blk_queue_ida, q->id);
It's not clear to me how that remove call could happen *before* q->id is removed
from the blkcg radix tree.
Bart.
Powered by blists - more mailing lists