All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2021-11-30 11:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-25 17:28 Use after free with BFQ and cgroups Jan Kara
2021-11-26 14:47 ` Michal Koutný
2021-11-26 14:47   ` Michal Koutný
2021-11-29 17:11   ` Jan Kara
2021-11-29 17:11     ` Jan Kara
2021-12-09  2:23     ` yukuai (C)
2021-12-09  2:23       ` yukuai (C)
2021-12-09 15:33       ` Paolo Valente
2021-12-09 15:33         ` Paolo Valente
2021-12-13 17:33       ` Jan Kara
2021-12-14  1:24         ` yukuai (C)
2021-12-14  1:24           ` yukuai (C)
2021-12-20 18:38           ` Jan Kara
2021-12-20 18:38             ` Jan Kara
2021-12-22 15:21       ` Jan Kara
2021-12-22 15:21         ` Jan Kara
2021-12-23  1:02         ` yukuai (C)
2021-12-23  1:02           ` yukuai (C)
2021-12-23 17:13           ` Jan Kara
2021-12-23 17:13             ` Jan Kara
2021-11-29 17:12   ` Tejun Heo
2021-11-30 11:50     ` Jan Kara [this message]
2021-11-30 16:22       ` Tejun Heo
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 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.