On 3/3/26 5:02 PM, Eelco Chaudron wrote:
>
>
> On 3 Mar 2026, at 15:23, Eelco Chaudron wrote:
>
>> On 9 Feb 2026, at 14:29, Eli Britstein wrote:
>>
>>> From: Gaetan Rivet <[email protected]>
>>>
>>> Implicit padding bytes in a struct are not necessarily initialized.
>>> Comparing such struct with memcmp might be wrong. To verify correctness
>>> of such comparison, add a macro to statically assert whether a structure
>>> contains padding.
>>
>> Thanks for the patch, Gaetan. Some small nits below.
>
> I was thinking about this again after a coffee break, and it seems odd to
> define a structure with a macro. Maybe the build assert should just follow
> the structure definition? Something like the below more in line with the
> Other BUILD_ASSERT_xxx macros:
>
> struct key {
> size_t idx;
> bool b;
> uint8_t pad[7];
> };
> BUILD_ASSERT_PACKED(struct key);
>
> Ilya is already copied, but maybe he has some thoughts around this...
I'm not sure how useful this macro is in general, as the only real
use for it seem to be this one:
OVS_ASSERT_PACKED(struct netdev_doca_esw_key,
struct rte_pci_addr rte_pci;
);
And this practically guarantees nothing as we don't know if the struct
rte_pci_addr has any wholes in it, and the macro will not guarantee
that it doesn't.
And, in fact, the 'struct rte_pci_addr' actually has 1 byte of padding:
struct rte_pci_addr {
uint32_t domain; /* 0 4 */
uint8_t bus; /* 4 1 */
uint8_t devid; /* 5 1 */
uint8_t function; /* 6 1 */
/* size: 8, cachelines: 1, members: 4 */
/* padding: 1 */
/* last cacheline: 8 bytes */
};
So, it doesn't look like we need this patch and the users of the refmap
just need to make sure to always fully initialize the key structure with
a memset or xzalloc on allocation.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
