Re: [PATCH] bonding: Always assign be16 value to vlan_proto

[Jay Vosburgh <jay.vosburgh@canonical.com>]

Vladimir Oltean <olteanv@gmail.com> wrote:

>On Thu, Apr 20, 2023 at 12:47:33PM -0700, Jay Vosburgh wrote:
>> Simon Horman <horms@kernel.org> wrote:
>> 
>> >The type of the vlan_proto field is __be16.
>> >And most users of the field use it as such.
>> >
>> >In the case of setting or testing the field for the
>> >special VLAN_N_VID value, host byte order is used.
>> >Which seems incorrect.
>> >
>> >Address this issue by converting VLAN_N_VID to __be16.
>> >
>> >I don't believe this is a bug because VLAN_N_VID in
>> >both little-endian (and big-endian) byte order does
>> >not conflict with any valid values (0 through VLAN_N_VID - 1)
>> >in big-endian byte order.
>> 
>> 	Is that true for all cases, or am I just confused?  Doesn't VLAN
>> ID 16 match VLAN_N_VID (which is 4096) if byte swapped?
>> 
>> 	I.e., on a little endian host, VLAN_N_VID is 0x1000 natively,
>> and network byte order (big endian) of VLAN ID 16 is also 0x1000.
>> 
>> 	Either way, I think the change is fine; VLAN_N_VID is being used
>> as a sentinel value here, so the only real requirement is that it not
>> match an actual VLAN ID in network byte order.
>> 
>> 	-J
>
>In a strange twist of events, VLAN_N_VID is assigned as a sentinel value
>to a variable which usually holds the output of vlan_dev_vlan_proto(),
>or i.o.w. values like htons(ETH_P_8021Q), htons(ETH_P_8021AD). It is
>certainly a confusion of types to assign VLAN_N_VID to it, but at least
>it's not a valid VLAN protocol.
>
>To answer your question, tags->vlan_proto is never compared against a
>VLAN ID.

	Yah, looking again I see that now; I was checking the math on
Simon's statement about "0 through VLAN_N_VID - 1".

	So, I think the patch is correct, but the commit message should
really explain the reality.  And, perhaps we should use 0 or 0xffff for
the sentinel, since neither are valid Ethernet protocol IDs.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com