From: Jan Kara <jack@suse.cz>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Jan Kara <jack@suse.cz>, Paolo Valente <paolo.valente@linaro.org>,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, fvogt@suse.de,
Tejun Heo <tj@kernel.org>,
cgroups@vger.kernel.org, stable@vger.kernel.org,
Fabian Vogt <fvogt@suse.com>
Subject: Re: [PATCH] bfq: Fix use-after-free with cgroups
Date: Mon, 13 Dec 2021 15:52:31 +0100 [thread overview]
Message-ID: <20211213145231.GD14044@quack2.suse.cz> (raw)
In-Reply-To: <20211207190843.GA40898@blackbody.suse.cz>
On Tue 07-12-21 20:08:43, Michal Koutný wrote:
> On Wed, Dec 01, 2021 at 02:34:39PM +0100, Jan Kara <jack@suse.cz> wrote:
> > After some analysis we've found out that the culprit of the problem is
> > that some task is reparented from cgroup G to the root cgroup and G is
> > offlined.
>
> Just sharing my interpretation for context -- (I saw this was a system
> using the unified cgroup hierarchy, io_cgrp_subsys_on_dfl_key was
> enabled) and what was observed could also have been disabling the io
> controller on given level -- that would also manifest similarly -- the
> task is migrated to parent and the former blkcg is offlined.
Yes, that's another possibility.
> > +static void bfq_reparent_children(struct bfq_data *bfqd, struct bfq_group *bfqg)
> > [...]
> > - bfq_bfqq_move(bfqd, bfqq, bfqd->root_group);
> > [...]
> > + hlist_for_each_entry_safe(bfqq, next, &bfqg->children, children_node)
> > + bfq_bfqq_move(bfqd, bfqq, bfqd->root_group);
>
> Here I assume root_group is (representing) the global blkcg root and
> this reparenting thus skips all ancestors between the removed leaf and
> the root. IIUC the associated io_context would then be treated as if it
> was running in the root blkcg.
> (Admittedly, this isn't a change from this patch but it may cause some
> surprises if the given process runs after the operation.)
Yes, this is what happens in bfq_reparent_children() and basically
preserves what BFQ was already doing for a subset of bfq queues.
> Reparenting to the immediate ancestors should be safe as cgroup core
> should ensure children are offlined before parents. Would it make sense
> to you?
I suppose yes, it makes more sense to reparent just to immediate parents
instead of the root of the blkcg hierarchy. Initially when developing the
patch I was not sure whether parent has to be still alive but as you write
it should be safe. I'll modify the patch to:
static void bfq_reparent_children(struct bfq_data *bfqd, struct bfq_group *bfqg)
{
struct bfq_queue *bfqq;
struct hlist_node *next;
struct bfq_group *parent;
parent = bfqg_parent(bfqg);
if (!parent)
parent = bfqd->root_group;
hlist_for_each_entry_safe(bfqq, next, &bfqg->children, children_node)
bfq_bfqq_move(bfqd, bfqq, parent);
}
> > @@ -897,38 +844,17 @@ static void bfq_pd_offline(struct blkg_policy_data *pd)
> > [...]
> > - * It may happen that some queues are still active
> > - * (busy) upon group destruction (if the corresponding
> > - * processes have been forced to terminate). We move
> > - * all the leaf entities corresponding to these queues
> > - * to the root_group.
>
> This comment is removed but it seems to me it assumed that the
> reparented entities are only some transitional remainings of terminated
> tasks but they may be the processes migrated upwards with a long (IO
> active) life ahead.
Yes, this seemed to be a misconception of the old code...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2021-12-13 14:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 13:34 [PATCH] bfq: Fix use-after-free with cgroups Jan Kara
2021-12-01 16:47 ` kernel test robot
2021-12-01 21:22 ` kernel test robot
2021-12-07 14:53 ` Holger Hoffstätte
[not found] ` <28ded939-6339-c9e1-c0a3-ff84fb197eed-yRdLqooqVXZ9NkuW+OO3NY3UfPj+9hkl@public.gmane.org>
2021-12-13 13:46 ` Jan Kara
2021-12-07 19:08 ` Michal Koutný
2021-12-13 14:52 ` Jan Kara [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=20211213145231.GD14044@quack2.suse.cz \
--to=jack@suse.cz \
--cc=axboe@kernel.dk \
--cc=cgroups@vger.kernel.org \
--cc=fvogt@suse.com \
--cc=fvogt@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=paolo.valente@linaro.org \
--cc=stable@vger.kernel.org \
--cc=tj@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