config-wsl: CONFIG_MEMCG_V1 disabled in 6.18.y kernel, removes cgroup v1 memory controller

[mat007]

Summary

Since the move to the linux-msft-wsl-6.18.y kernel, the cgroup v1 memory controller is disabled (# CONFIG_MEMCG_V1 is not set). The memory controller no longer appears in /proc/cgroups and a cgroup v1 memory hierarchy can no longer be mounted, even though CONFIG_MEMCG=y and cgroup v2 memory accounting works fine.

This looks unintentional: only the v1 memory controller was turned off, while the sibling v1 controllers were kept.

Windows Version

10.0.26100.8655

WSL Version

2.7.8.0

Are you using WSL 1 or WSL 2?

WSL 2

Kernel Version

6.18.33.1-microsoft-standard-WSL2

Distro Version

Ubuntu 24.04 (reproduces on any distro, the kernel is shared)

Other Software

None required to reproduce. The symptom also surfaces in any runtime that reads the cgroup v1 memory interface (for example OpenJDK container detection, JDK-8347129 / JDK-8349527).

Repro Steps

On WSL 2.7.8 (kernel 6.18.33.1-microsoft-standard-WSL2), in any distro:

grep -w memory /proc/cgroups || echo "MISSING: no v1 memory controller"
sudo mkdir -p /tmp/memcg
sudo mount -t cgroup -o memory none /tmp/memcg

The grep reports MISSING and the mount fails. Running the same on the previous 6.6.y WSL kernel lists memory and mounts successfully.

Expected Behavior

The cgroup v1 memory controller is available: a memory row appears in /proc/cgroups and a v1 memory hierarchy can be mounted, as on the 6.6.y WSL kernel.

Actual Behavior

memory is absent from /proc/cgroups and the v1 memory hierarchy cannot be mounted. cgroup v2 memory accounting still works, so only the v1 interface is affected.

Only the v1 memory controller was turned off, while the sibling v1 controllers were kept:

# CONFIG_MEMCG_V1 is not set      <- v1 memory controller OFF
CONFIG_CPUSETS_V1=y               <- v1 cpuset controller ON

Every other v1 controller is still present in /proc/cgroups (cpuset, cpu, cpuacct, blkio, devices, freezer, net_cls, perf_event, net_prio, hugetlb, pids, rdma). CONFIG_MEMCG_V1 defaults to n upstream (since 6.11) while CONFIG_CPUSETS_V1 defaults to y, so this reads like make olddefconfig accepting defaults during the 6.18 refresh rather than a deliberate choice.

There is no userspace workaround: with CONFIG_MEMCG_V1=n the v1 code (mm/memcontrol-v1.o) is not compiled, so cgroup_enable=memory cannot restore it. (cgroup_v1_proc=1 only un-hides the row in /proc/cgroups, it does not rebuild the controller.)

Diagnostic Logs

Regression point: microsoft/WSL2-Linux-Kernel@f1fbea113b67 ("olddefconfig for 6.18.9.4"), in both arch/x86/configs/config-wsl and arch/arm64/configs/config-wsl-arm64.

Before (6.6.y base, 610631f4cf4b):

CONFIG_MEMCG=y
CONFIG_MEMCG_KMEM=y

After (first 6.18 olddefconfig, f1fbea113b67):

CONFIG_MEMCG=y
# CONFIG_MEMCG_V1 is not set

This kernel reached users as 6.18.33.1-microsoft-standard-WSL2 in WSL 2.7.8 (#40728).

Proposed fix

Set CONFIG_MEMCG_V1=y in arch/x86/configs/config-wsl and arch/arm64/configs/config-wsl-arm64, matching how CONFIG_CPUSETS_V1=y was kept. This restores the v1 memory interface without affecting cgroup v2.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[mat007]

Logs: WslLogs-2026-06-19_17-53-19.tar.gz

[github-actions]

Diagnostic information

Detected appx version: 2.7.8.0