[randomizedcoder]

Linux 7.1 changed two APIs that Homa uses, so main doesn't build on 7.1, 7.2 or 7.3:

• proto.recvmsg lost addr_len (8341c989ac77). This adds homa_recvmsg_proto, a small adapter that does what sock_common_recvmsg used to: it starts addr_len at 0, calls homa_recvmsg, and sets msg->msg_namelen on success. homa_recvmsg and its unit tests are unchanged.
• net_hotdata.rps_sock_flow_table became an rps_tag_ptr (dd378109d20f). homa_set_softirq_cpu now uses rps_tag_to_table/rps_tag_to_mask on 7.1+, mirroring the kernel's rps_record_sock_flow.

Builds against 6.12, 6.19.9, 7.0.14, 7.1.13, 7.2.12, 7.3-rc7 and 7.3, and the unit tests pass. Also loaded in a 7.3.0 VM, where loopback request/response RPCs (100 B to 1 MB) complete through the new recvmsg path and dmesg stays clean.

No test: compile-time only, and the unit harness builds against the 6.17.8/7.0.14 objects, where the new code isn't compiled.

Not covered here: 6.18 stable backported the recvmsg change in 6.18.40 and the sockaddr_unsized bind change in 6.18.57, so current 6.18 LTS still doesn't build. That needs a separate, finer-grained gate: test/mock.c uses SOCKADDR for connect, which 6.18.57 did not convert.

🤖 Generated with Claude Code

[breakertt]

There were some discussions on this between John and Tiara just recently #110 (comment)

I agree, and I also think we should move support from a random kernel version number (i.e. 6.17.8) to the latest LTS version, if we mainly maintain support for one kernel version.

I am trying to introduce some basic CI (#119) so we can quickly know when it doesn’t build.

But it still depends on John, as he is mainly working on this repo and his convenience matters most IMO.

[randomizedcoder]

Thanks for the quick reply! I've got a flake.nix and modular nix that does a lot of static analysis, fuzzing, and will test against a wide range of kernels. This is easy to hook up with CI.

[breakertt]

Unfortunately I am not a big fan of Nix, but I am also not anti-Nix. Overall I feel we should be able to have those abilities without Nix, for less maintenance burden. Do you think that if we use Nix for CI, the CI will still be easy to understand for non-NixOS users? If so, I am actually open to that.

[breakertt]

Unfortunately I am not a big fan Nix, but I am also anti Nix. Just overall I feel we should able to have those abilities without Nix for less maintaince burden? Do you think if we use Nix for CI - the CI will easier to understand for non NixOS user? If so I am actually open to that.

Sorry I mean I am not anti-NixOS, it was a typo 🫣

[johnousterhout]

Thanks for this patch. I'm doing some surgery on it (a) to use the homa_set_softirq_cpu code from the net-next branch (which has some comments to explain its behavior; the code is nearly identical and functionally equivalent) and (b) so that it strips cleanly for upstreaming (e.g. the HOMA_RECVMSG_NO_ADDR_LEN will be unacceptable in upstreamed code). When I push it (soon), can you check to be sure that I haven't broken anything?

Also, when the next LTS version is announced (perhaps in November?) my plan is to upgrade the main branch to that for development, and from then on use LTS versions as the primary version for development.

[breakertt]

Next LTS - this year is tricky as 7.3 published in mid October so there maybe some uncertainty whether 7.3 is the last version year. Waiting for Greg’s decision.

[randomizedcoder]

Checked main at 4bd0275 (includes e65a5c0 + 4e1ebd6) — nothing broken that I can find:

Check	Result
Module build	✅ 6.12.113, 7.0.14, 7.1.13, 7.2.12, 7.3; __STRIP__=1 clean on 7.3
Unit tests	✅ 884/884 (IPv6 and --ipv4)
VM run, 7.3	✅ echo 100 B–1 MB; netns/veth with GRO + RPS: 1737 homa_gro_receive, 470 homa_set_softirq_cpu calls (the rps_tag_ptr path)
VM run, 6.12	✅ same, 1722 / 450 calls (the pre-7.1 path)

So both sides of the 7.1 gate work.

One thing relevant to the LTS plan: 6.18-stable backported both API changes (the recvmsg addr_len removal in 6.18.40, and sockaddr_unsized for bind in 6.18.57). With the < KERNEL_VERSION(7, 1, 0) / (7, 0, 0) gates, 6.18.57+ picks the old signatures and fails to build (incompatible-pointer-types is an error with gcc 15). If main moves to 7.3 or later this goes away; if 6.18 is the target I can send a small fix for the gates — just let me know which you'd prefer.

@breakertt re CI: agreed it should work without Nix — #119/#133 look like the right path. I'll keep the Nix tooling (multi-kernel builds, fuzzing, VM tests) on my fork and just report anything it finds.

[johnousterhout]

The plan is for the first LTS commit to be 7.3 or later, so I don't think we need to make updates for Homa to compile on 6.18 LTS. Thanks for offering, though.

…

-John-

On Wed, Oct 28, 2026 at 7:18 PM randomizedcoder ***@***.***> wrote: *randomizedcoder* left a comment (PlatformLab/HomaModule#120) <#120 (comment)> Checked main at 4bd0275 <4bd0275> (includes e65a5c0 <e65a5c0> + 4e1ebd6 <4e1ebd6>) — nothing broken that I can find: Check Result Module build ✅ 6.12.113, 7.0.14, 7.1.13, 7.2.12, 7.3; __STRIP__=1 clean on 7.3 Unit tests ✅ 884/884 (IPv6 and --ipv4) VM run, 7.3 ✅ echo 100 B–1 MB; netns/veth with GRO + RPS: 1737 homa_gro_receive, 470 homa_set_softirq_cpu calls (the rps_tag_ptr path) VM run, 6.12 ✅ same, 1722 / 450 calls (the pre-7.1 path) So both sides of the 7.1 gate work. One thing relevant to the LTS plan: 6.18-stable backported both API changes (the recvmsg addr_len removal in 6.18.40, and sockaddr_unsized for bind in 6.18.57). With the < KERNEL_VERSION(7, 1, 0) / (7, 0, 0) gates, 6.18.57+ picks the old signatures and fails to build (incompatible-pointer-types is an error with gcc 15). If main moves to 7.3 or later this goes away; if 6.18 is the target I can send a small fix for the gates — just let me know which you'd prefer. @breakertt <https://github.com/breakertt> re CI: agreed it should work without Nix — #119 <#119>/ #133 <#133> look like the right path. I'll keep the Nix tooling (multi-kernel builds, fuzzing, VM tests) on my fork and just report anything it finds. — Reply to this email directly, view it on GitHub <#120?email_source=notifications&email_token=ACOOUCT5KPLWQVOD4NZG4ZL5WKSGFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBYGYYDMMJQG4Y2M4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6486061071>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOOUCQ3Q2JWRIQTJ2PJFYL5WKSGFAVCNFSNUABFKJSXA33TNF2G64TZHMYTGOJWGM3DANZXHNEXG43VMU5TKOJXGQ4DCNRQGIZ2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ACOOUCRVMWADCW64MWZPIJT5WKSGFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBYGYYDMMJQG4Y2M4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ACOOUCRCYIV4VVBHJDMPXQL5WKSGFA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMNBYGYYDMMJQG4Y2M4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you modified the open/close state.Message ID: ***@***.***>