[randomizedcoder]

struct sock has sk_memcg only when CONFIG_MEMCG is set (since 6.18). In a kernel without memory cgroups (x86_64 and i386 defconfig, for example), homa_rpc_alloc_server doesn't compile:

net/homa/homa_rpc.c:134:22: error: 'struct sock' has no member named 'sk_memcg'

The out-of-tree build only passes because distro kernels enable memcg.

Fix: from 6.18, read it with mem_cgroup_from_sk(). Under CONFIG_MEMCG that returns sk->sk_memcg; without it, it returns NULL, so the allocation takes the existing non-accounted path. Before 6.18 the field is unconditional and mem_cgroup_from_sk() doesn't exist, so a LINUX_VERSION_CODE check reads the field directly. Behaviour is unchanged when memcg is on, and the stripped output is the 6.18+ form.

Checked:

• 886/886 unit tests pass.
• The module builds against 6.17.8 and 7.3, normally, with __STRIP__=1, and against a KASAN/lockdep 7.3 kernel. The previous version of this commit reproduces the 6.17 mem_cgroup_from_sk error.
• The stripped files build in a 7.3 tree (defconfig + HOMA=m, W=1; gcc + sparse, clang, i386) with no warnings, once a separate one-line fix for a new set-but-unused variable in homa_pool.c (from the pool rework) is applied too; that one will follow as its own PR.

No test, since it's a build fix.

🤖 Generated with Claude Code

[johnousterhout]

This PR doesn't build on Homa's main branch (6.17.8): mem_cgroup_from_sk isn't present in that version of Linux. Can you modify it to behave properly when mem_cgroup_from_sk isn't present?

[randomizedcoder]

Thanks John, fixed. mem_cgroup_from_sk arrived in 6.18, along with the CONFIG_MEMCG guard on sk_memcg, so it now uses a LINUX_VERSION_CODE check and reads the field directly before 6.18. The stripped output is unchanged. Our test matrix was missing 6.17.8, so we've added it; this now builds there, and the old commit reproduces your error.