percpu_ref_init(): clean ->percpu_count_ref on failure
authorAl Viro <viro@zeniv.linux.org.uk>
Wed, 18 May 2022 06:13:40 +0000 (02:13 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 6 Jun 2022 06:43:36 +0000 (08:43 +0200)
commit20b413c38b7c36b4251f55ec656644d10af59e2f
tree2f86bc18c3aa0e2e3d350028e74ea7c2dde2e507
parent8243f5768dea24fe286a6323dc200225e7cff891
percpu_ref_init(): clean ->percpu_count_ref on failure

[ Upstream commit a91714312eb16f9ecd1f7f8b3efe1380075f28d4 ]

That way percpu_ref_exit() is safe after failing percpu_ref_init().
At least one user (cgroup_create()) had a double-free that way;
there might be other similar bugs.  Easier to fix in percpu_ref_init(),
rather than playing whack-a-mole in sloppy users...

Usual symptoms look like a messed refcounting in one of subsystems
that use percpu allocations (might be percpu-refcount, might be
something else).  Having refcounts for two different objects share
memory is Not Nice(tm)...

Reported-by: syzbot+5b1e53987f858500ec00@syzkaller.appspotmail.com
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
lib/percpu-refcount.c