Re: [syzbot] [mm?] [cgroups?] WARNING: bad unlock balance in lruvec_stat_mod_folio

[Qi Zheng <qi.zheng@linux.dev>]

On 4/15/26 1:15 AM, Shakeel Butt wrote:
> On Tue, Apr 14, 2026 at 11:52:13AM +0800, Qi Zheng wrote:
>> Hi Shakeel,
>>
>> On 4/14/26 6:28 AM, Shakeel Butt wrote:
>>> +Qi & Yosry
>>>
>>> On Tue, Apr 07, 2026 at 10:53:24AM -0700, syzbot wrote:
>>>> Hello,
>>>>
>>>> syzbot found the following issue on:
>>>>
>>>> HEAD commit:    cc13002a9f98 Add linux-next specific files for 20260402
>>>> git tree:       linux-next
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=10d8946a580000
>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=4e6c8be618ab359
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=1a3353a77896e73a8f53
>>>> compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>>>>
>>>> Unfortunately, I don't have any reproducer for this issue yet.
>>>
>>> Let's wait for the reproducer. I can only think of cgroup_subsys_on_dfl() check
>>> returning different value in get_non_dying_memcg_start() and
>>> get_non_dying_memcg_end() to cause this uneven rcu unlock. However I can't think
>>> why and how that can happen.
>>>
>>
>> My AI bot told me that the cgroup_subsys_on_dfl_key can be dynamically
>> modified at runtime during a rebind:
>>
>> rebind_subsystems()
>> --> if (dst_root == &cgrp_dfl_root) {
>> 		static_branch_enable(cgroup_subsys_on_dfl_key[ssid]);
>>      } else {
>> 		dcgrp->subtree_control |= 1 << ssid;
>> 		static_branch_disable(cgroup_subsys_on_dfl_key[ssid]);
>>      }
>>
>> However, when I actually tested it, I hit the following error:
>>
>> mount: /tmp/cg-rb-repro: mount point is busy.
>>
>> Indeed, there are already many child cgroups under the cgroup v2 root
>> (the VM just booted):
>>
>> root@localhost:~# find /sys/fs/cgroup -mindepth 1 -maxdepth 2 -type d | head
>> -50
>> /sys/fs/cgroup/sys-kernel-debug.mount
>> /sys/fs/cgroup/dev-mqueue.mount
>> /sys/fs/cgroup/user.slice
>> /sys/fs/cgroup/user.slice/user-0.slice
>> /sys/fs/cgroup/sys-kernel-tracing.mount
>> /sys/fs/cgroup/init.scope
>> /sys/fs/cgroup/system.slice
>> /sys/fs/cgroup/system.slice/systemd-networkd.service
>> /sys/fs/cgroup/system.slice/systemd-udevd.service
>> /sys/fs/cgroup/system.slice/system-serial\x2dgetty.slice
>> /sys/fs/cgroup/system.slice/wpa_supplicant.service
>> /sys/fs/cgroup/system.slice/system-modprobe.slice
>> /sys/fs/cgroup/system.slice/systemd-journald.service
>> /sys/fs/cgroup/system.slice/unattended-upgrades.service
>> /sys/fs/cgroup/system.slice/system-systemd\x2dgrowfs.slice
>> /sys/fs/cgroup/system.slice/ssh.service
>> /sys/fs/cgroup/system.slice/dhcpcd.service
>> /sys/fs/cgroup/system.slice/systemd-resolved.service
>> /sys/fs/cgroup/system.slice/dbus.service
>> /sys/fs/cgroup/system.slice/systemd-timesyncd.service
>> /sys/fs/cgroup/system.slice/system-getty.slice
>> /sys/fs/cgroup/system.slice/systemd-logind.service
>> /sys/fs/cgroup/dev-hugepages.mount
>>
>> So it seems impossible to rebind memory in a production environment
>> using systemd?
>>
>> Then I disabled systemd:
>>
>> set `init=/bin/bash`
>>
>> and found that I could successfully run the following commands:
>>
>> root@(none):/# mkdir -p /tmp/cg-rb-repro
>> root@(none):/# mount -t cgroup -o none,name=rb none /tmp/cg-rb-repro
>> root@(none):/# mount -t cgroup -o remount,memory none /tmp/cg-rb-repro
>> [   65.903125][  T241] option changes via remount are deprecated (pid=241
>> comm=mount)
>> root@(none):/# mount -t cgroup -o remount,name=rb none /tmp/cg-rb-repro
>> [   73.405829][  T242] option changes via remount are deprecated (pid=242
>> comm=mount)
>> root@(none):/# umount /tmp/cg-rb-repro
>>
>> So it seems this race condition does exist. Should we fix it?
> 
> This only succeeded because there weren't any active cgroups. Were you able to
> trigger the warning as well. If not, I think we should just wait for

Nope.

> reproducer from syzbot before doing anything.

OK, Let's wait for syzbot to reproduce it.

>