linux-kernel - Re: [PATCH] net: define IPPROTO_SMBDIRECT and SOL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3dd5c950-e3e4-42b8-a40b-f0ee04feb563@redhat.com>
Date: Thu, 27 Nov 2025 17:34:49 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Stefan Metzmacher <metze@...ba.org>, netdev@...r.kernel.org
Cc: "David S . Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Simon Horman <horms@...nel.org>, Kuniyuki Iwashima <kuniyu@...gle.com>,
 Willem de Bruijn <willemb@...gle.com>, Steve French <smfrench@...il.com>,
 Tom Talpey <tom@...pey.com>, Long Li <longli@...rosoft.com>,
 Namjae Jeon <linkinjeon@...nel.org>, Xin Long <lucien.xin@...il.com>,
 linux-kernel@...r.kernel.org, linux-cifs@...r.kernel.org,
 samba-technical@...ts.samba.org, linux-rdma@...r.kernel.org
Subject: Re: [PATCH] net: define IPPROTO_SMBDIRECT and SOL_SMBDIRECT constants

On 11/26/25 12:14 PM, Stefan Metzmacher wrote:
> In order to avoid conflicts with the addition of IPPROTO_QUIC,
> the patch is based on netdev-next/main + the patch adding
> IPPROTO_QUIC and SOL_QUIC [2].
> 
> [2]
> https://lore.kernel.org/quic/0cb58f6fcf35ac988660e42704dae9960744a0a7.1763994509.git.lucien.xin@gmail.com/T/#u
> 
> As the numbers of IPPROTO_QUIC and SOL_QUIC are already used
> in various userspace applications it would be good to have
> this merged to netdev-next/main even if the actual
> implementation is still waiting for review.

Let me start from here... Why exactly? such applications will not work
(or at least will not use IPPROTO_QUIC) without the actual protocol
implementation.

Build time issues are much more easily solved with the usual:

#ifndef IPPROTO_*
#define IPPROTO_
#endif

that the application code should still carry for a bit of time (until
all the build hosts kernel headers are updated).

The above considerations also apply to this patch. What is the net
benefit? Why something like the above preprocessor's macros are not enough?

We need at least to see the paired implementation to accept this patch,
and I personally think it would be better to let the IPPROTO definition
and the actual implementation land together.

Cheers,

Paolo