From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 11 Oct 2006 15:11:18 +0200
> Using memcmp(ptr1, ptr2, sizeof(SOMEFIELD)) is dangerous because
> sizeof(SOMEFIELD) can be larger than the underlying object, because of
> alignment constraints.
>
> In this case, sizeof(fl1->nl_u.ip4_u) is 16, while fl1->nl_u.ip4_u is :
>
> struct {
> __u32 daddr;
> __u32 saddr;
> __u32 fwmark;
> __u8 tos;
> __u8 scope;
> } ip4_u;
>
> So 14 bytes are really initialized, and 2 padding bytes might contain random
> values...
We always explicitly initialize the flows, and even for local stack
assignment based initialization, gcc zeros out the padding bytes
always. For non-stack-local cases we do explicit memset()'s over the
entire object. So I think while not perfect, we're very much safe
here.
> fast comparison, we should do some clever long/int XOR operations to avoid
> many test/branches, like the optim we did in compare_ether_addr())
>
> As shown in profiles, "repz cmpsb" is really a dog... (and its use of
> esi/edi/ecx registers a high pressure for the compiler/optimizer)
Yes, for the fast comparisons it is almost certainly worth it to do
something saner in compare_keys().
But looking at this further, compare_keys() is only used in hotpath
situations where we are optimizing for a miss, such as during hash
insert. The optimization therefore might be less justified as a
result.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
