Al Viro a91714312e percpu_ref_init(): clean ->percpu_count_ref on failure
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>
2022-05-18 02:20:17 -04:00
..
2021-07-08 11:48:20 -07:00
2022-03-23 12:56:39 -07:00
2020-08-09 14:10:26 -07:00
2021-09-08 11:50:26 -07:00
2022-03-03 10:47:52 +12:00
2021-07-08 11:48:20 -07:00
2021-07-08 11:48:20 -07:00
2021-11-18 13:16:22 -08: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
2022-03-07 12:48:35 -07:00
2021-08-19 09:02:55 +09:00
2021-01-03 20:05:18 -05:00
2022-01-15 08:47:31 -08:00
2022-03-07 12:48:35 -07:00
2020-10-20 14:39:37 -07:00
2021-08-19 09:02:55 +09:00
2022-03-24 18:07:03 -07:00
2021-07-08 11:48:20 -07:00
2022-01-20 08:52:53 +02:00
2021-07-08 11:48:20 -07:00
2022-03-26 12:19:04 -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-06-18 11:43:09 +02:00
2021-07-08 11:48:20 -07:00
2022-01-20 08:52:54 +02:00
2018-10-15 16:31:29 -04:00