[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67ae1142e9bdd_24be452947e@willemb.c.googlers.com.notmuch>
Date: Thu, 13 Feb 2025 10:35:30 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Paolo Abeni <pabeni@...hat.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
netdev@...r.kernel.org
Cc: davem@...emloft.net,
kuba@...nel.org,
edumazet@...gle.com,
dsahern@...nel.org,
horms@...nel.org,
Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net-next v2 2/7] net: initialize mark in sockcm_init
Paolo Abeni wrote:
> On 2/12/25 3:09 AM, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@...gle.com>
> >
> > Avoid open coding initialization of sockcm fields.
> > Avoid reading the sk_priority field twice.
> >
> > This ensures all callers, existing and future, will correctly try a
> > cmsg passed mark before sk_mark.
> >
> > This patch extends support for cmsg mark to:
> > packet_spkt and packet_tpacket and net/can/raw.c.
> >
> > This patch extends support for cmsg priority to:
> > packet_spkt and packet_tpacket.
>
> I admit I'm a little bit concerned vs possibly impacting existing
> applications doing weird thing like passing the relevant cmsg and
> expecting it to be ignored.
We have a history of expanding support for passing variables by cmsg.
These APIs are intended to be uniform across protocols, at least
across all datagram cases. Existing behavior is arbitrary and
unintentional, where a new feature was added only to the protocol
most on the developer's mind.
The goal of deduplicating is exactly to avoid more such arbitrary
limitations as new fields are added.
> Too paranoid on my side?
Not at all!
For correctness, besides code inspection for this series I also
relied on existing kselftests including cmsg_ipv6.sh and
cmsg_so_priority.sh. I added a cmsg_ipv4.sh to verify the subtle
routing point in patch 4. But that is not ready to submit yet.
Powered by blists - more mailing lists