Al Viro 20b413c38b 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>
2022-06-06 08:43:36 +02:00
..
2022-05-18 10:26:49 +02:00
2021-07-08 11:48:20 -07:00
2020-08-09 14:10:26 -07:00
2021-09-08 11:50:26 -07:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-05-06 19:24:12 -07:00
2018-08-16 12:14:42 -07:00
2021-01-21 14:06:00 -07:00
2021-06-05 08:58:12 -07:00
2021-08-19 09:02:55 +09:00
2021-07-08 11:48:20 -07:00
2021-01-03 20:05:18 -05:00
2020-10-20 14:39:37 -07:00
2021-08-19 09:02:55 +09:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2018-10-16 13:45:44 +02:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-08-08 13:00:20 +01:00
2021-09-17 13:52:17 +01:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-06-18 11:43:09 +02:00
2021-07-08 11:48:20 -07:00
2018-10-15 16:31:29 -04:00
2021-08-13 13:19:06 -06:00