From: Jan Kara <jack@suse.cz>
To: Tejun Heo <tj@kernel.org>
Cc: "Michal Koutný" <mkoutny@suse.com>, "Jan Kara" <jack@suse.cz>,
"Paolo Valente" <paolo.valente@linaro.org>,
linux-block@vger.kernel.org, fvogdt@suse.de,
cgroups@vger.kernel.org
Subject: Re: Use after free with BFQ and cgroups
Date: Tue, 30 Nov 2021 12:50:10 +0100 [thread overview]
Message-ID: <20211130115010.GF7174@quack2.suse.cz> (raw)
In-Reply-To: <YaUKCoK39FlZK9m5@slm.duckdns.org>
On Mon 29-11-21 07:12:42, Tejun Heo wrote:
> On Fri, Nov 26, 2021 at 03:47:24PM +0100, Michal Koutný wrote:
> > The question here is how long would stay the offlined blkcgs around if
> > they were directly pinned upon the IO submission. If it's unbound, then
> > reparenting makes more sense.
>
> It should be fine to pin whatever's necessary while related IOs are in
> flight and percpu_ref used for css refcnting isn't gonna make any noticeable
> difference in terms of overhead.
Yes, holding cgroup ref from IO would be fine. But that is not really our
problem.
The problem is bfq_queue associated with a task effectively holds a
reference to the potentially dead cgroup and the reference can stay there
until the task (that itself got reparented to the root cgroup) exits. So I
think we need to reparent these bfq_queue structures as well to avoid
holding cgroup in zombie state excessively long.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2021-11-30 11:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211125172809.GC19572@quack2.suse.cz>
[not found] ` <20211125172809.GC19572-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2021-11-26 14:47 ` Use after free with BFQ and cgroups Michal Koutný
[not found] ` <20211126144724.GA31093-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2021-11-29 17:11 ` Jan Kara
2021-12-09 2:23 ` yukuai (C)
[not found] ` <f03b2b1c-808a-c657-327d-03165b988e7d-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2021-12-09 15:33 ` Paolo Valente
2021-12-22 15:21 ` Jan Kara
[not found] ` <20211222152103.GF685-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2021-12-23 1:02 ` yukuai (C)
[not found] ` <d770663a-911c-c9c1-1185-558634f4c738-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2021-12-23 17:13 ` Jan Kara
2021-12-13 17:33 ` Jan Kara
[not found] ` <20211213173354.GE14044-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2021-12-14 1:24 ` yukuai (C)
[not found] ` <896161a3-922c-63b3-6e6f-9f6005a46bd4-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2021-12-20 18:38 ` Jan Kara
2021-11-29 17:12 ` Tejun Heo
2021-11-30 11:50 ` Jan Kara [this message]
[not found] ` <20211130115010.GF7174-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2021-11-30 16:22 ` Tejun Heo
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=20211130115010.GF7174@quack2.suse.cz \
--to=jack@suse.cz \
--cc=cgroups@vger.kernel.org \
--cc=fvogdt@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=paolo.valente@linaro.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