All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Koutný" <mkoutny@suse.com>
To: Tejun Heo <tj@kernel.org>
Cc: Tadeusz Struk <tadeusz.struk@linaro.org>,
	cgroups@vger.kernel.org, Zefan Li <lizefan.x@bytedance.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Christian Brauner <brauner@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzbot+e42ae441c3b10acf9e9d@syzkaller.appspotmail.com
Subject: Re: [PATCH] cgroup: don't queue css_release_work if one already pending
Date: Fri, 22 Apr 2022 13:05:06 +0200	[thread overview]
Message-ID: <20220422100400.GA29552@blackbody.suse.cz> (raw)
In-Reply-To: <YmHwOAdGY2Lwl+M3@slm.duckdns.org>

On Thu, Apr 21, 2022 at 02:00:56PM -1000, Tejun Heo <tj@kernel.org> wrote:
> If this is the case, we need to hold an extra reference to be put by the
> css_killed_work_fn(), right?

I looked into it a bit more lately and found that there already is such
a fuse in kill_css() [1].

At the same type syzbots stack trace demonstrates the fuse is
ineffective

> css_release+0xae/0xc0 kernel/cgroup/cgroup.c:5146                    (**)
> percpu_ref_put_many include/linux/percpu-refcount.h:322 [inline]
> percpu_ref_put include/linux/percpu-refcount.h:338 [inline]
> percpu_ref_call_confirm_rcu lib/percpu-refcount.c:162 [inline]        (*)
> percpu_ref_switch_to_atomic_rcu+0x5a2/0x5b0 lib/percpu-refcount.c:199
> rcu_do_batch+0x4f8/0xbc0 kernel/rcu/tree.c:2485
> rcu_core+0x59b/0xe30 kernel/rcu/tree.c:2722
> rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2735
> __do_softirq+0x27e/0x596 kernel/softirq.c:305

(*) this calls css_killed_ref_fn confirm_switch
(**) zero references after confirmed kill?

So, I was also looking at the possible race with css_free_rwork_fn()
(from failed css_create()) but that would likely emit a warning from
__percpu_ref_exit().

So, I still think there's something fishy (so far possible only via
artificial ENOMEM injection) that needs an explanation...

Michal

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/cgroup/cgroup.c#n5608


  reply	other threads:[~2022-04-22 11:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-12 19:24 [PATCH] cgroup: don't queue css_release_work if one already pending Tadeusz Struk
2022-04-14 16:44 ` Michal Koutný
2022-04-14 16:44   ` Michal Koutný
2022-04-14 17:51   ` Tadeusz Struk
2022-04-14 17:51     ` Tadeusz Struk
2022-04-21 23:43     ` Tejun Heo
2022-04-21 23:43       ` Tejun Heo
2022-04-22  0:00   ` Tejun Heo
2022-04-22 11:05     ` Michal Koutný [this message]
2022-05-18 16:48       ` Tadeusz Struk
2022-05-18 16:48         ` Tadeusz Struk
2022-05-19 11:23         ` Hillf Danton
2022-05-19 23:26           ` Tadeusz Struk
2022-05-20  8:13             ` Tejun Heo
2022-05-20 16:38               ` Tadeusz Struk
2022-05-20 16:42                 ` Michal Koutný
2022-05-20 16:56                   ` Tadeusz Struk
2022-05-23 19:00                   ` Tadeusz Struk
2022-05-23 19:02                     ` Tejun Heo
2022-05-23 19:08                       ` Tadeusz Struk
2022-05-23 20:05                         ` Tadeusz Struk
2022-05-20 23:48               ` Hillf Danton
2022-05-23 21:27 ` [PATCH v2] cgroups: separate destroy_work into two separate wq Tadeusz Struk
     [not found] <20220413095606.1182-1-hdanton@sina.com>
2022-04-13 15:39 ` [PATCH] cgroup: don't queue css_release_work if one already pending Tadeusz Struk

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=20220422100400.GA29552@blackbody.suse.cz \
    --to=mkoutny@suse.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hannes@cmpxchg.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+e42ae441c3b10acf9e9d@syzkaller.appspotmail.com \
    --cc=tadeusz.struk@linaro.org \
    --cc=tj@kernel.org \
    --cc=yhs@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.