Re: [PATCH bpf-next v2] bpf, unix: Guard sk_msg-dependent code behind CONFIG_NET_SOCK_MSG

[Jakub Sitnicki <jakub@cloudflare.com>]

On Wed, Jun 24, 2026 at 01:57 PM -07, Alexei Starovoitov wrote:
> On Tue Jun 23, 2026 at 6:32 PM PDT, Jiayuan Chen wrote:
>>
>> Hi Alexei and Jakub,
>>
>> skmsg is actually still pretty useful for gateways.
>> I started with bpf by integrating skmsg into nginx as a module and envoy 
>> has something similar.
>> The usual setup is cgroup/sk for L4 bypass (reject SYN), and skmsg for 
>> L7, redirecting
>> between local apps by looking at the payload. So there are real users.
>
> ...
>
>> Agree, just like we remove skmsg from KTLS which is rarely used.
>
> ...
>
>> Hope not have skmsg disabled by default.
>
> I wasn't suggesting to delete the whole skmsg,
> but to disable combinations that are causing issues.
> Like what was done for skmsg and ktls.
> I'd allow plain tcp and udp sockets only.
> Allowing unix sockets was fishy. I think we should reject it too.

For unix & vsock we know Bytedance built a proxy using it.
We've been showcasing it as one of sockmap use cases [1].
That said, I don't know if it's still being used or not.

If we don't want to go through the config-knob-then-deprecate process,
then I guess the only option is to kill it and see if anyone complains.

[1] Slide 117, https://github.com/sockmap-project/sockmap-project/blob/810d259af6e7a5793922af3991c9dc7ff502fe19/talks/2024-09%20-%20NDC%20TechTown%20-%20Splicing%20Sockets%20with%20SOCKMAP.pdf