Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-12 Thread David Miller
From: Eric Dumazet <[EMAIL PROTECTED]> Date: Thu, 12 Oct 2006 08:35:47 +0200 > How about avoiding the fwmark thing if !CONFIG_IP_ROUTE_FWMARK I've added that, good idea. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordom

Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread Eric Dumazet
David Miller a écrit : From: Eric Dumazet <[EMAIL PROTECTED]> Date: Thu, 12 Oct 2006 07:48:20 +0200 Not on my gcc here (gcc version 3.4.4) : It wont zeros out the padding bytes Patrick just proved this too :) Well, on this machine I have these oprofile numbers : : /* rt_intern_hash total:

Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread David Miller
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Thu, 12 Oct 2006 08:10:43 +0200 > David Miller wrote: > > Indeed, numbers talk bullshit walks :) > > :) > > > How about something like this as a start? > > > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c > > The same problem is also present

Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread Patrick McHardy
David Miller wrote: > Indeed, numbers talk bullshit walks :) :) > How about something like this as a start? > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c The same problem is also present in dn_route.c (3 uninitialized bytes in dn_u). - To unsubscribe from this list: send the line "unsub

Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread David Miller
From: Eric Dumazet <[EMAIL PROTECTED]> Date: Thu, 12 Oct 2006 07:48:20 +0200 > Not on my gcc here (gcc version 3.4.4) : It wont zeros out the padding bytes Patrick just proved this too :) > Well, on this machine I have these oprofile numbers : > > : /* rt_intern_hash total: 993464 0.3619 */ >

Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread David Miller
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Thu, 12 Oct 2006 07:31:12 +0200 > This program demonstrates the effect, it doesn't output the expected > "1 2" but "1 4294967042" on my x86_64 (gcc-Version 4.1.2 20060901 > (prerelease) (Debian 4.1.1-13)). The initialization doesn't touch > the paddi

Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread Eric Dumazet
David Miller a écrit : 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.ip

Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread Patrick McHardy
David Miller wrote: > We always explicitly initialize the flows, and even for local stack > assignment based initialization, gcc zeros out the padding bytes > always. I thought so too until I added the iptables compat functions recently and noticed uninitialized padding of on-stack structures, whi

Re: [RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread David Miller
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, whil

[RFC] Question about potential problem in net/ipv4/route.c

2006-10-11 Thread Eric Dumazet
Hi David While browsing net/ipv4/route.c I discovered compare_keys() function, and a potential bug in it. static inline int compare_keys(struct flowi *fl1, struct flowi *fl2) { return memcmp(&fl1->nl_u.ip4_u, &fl2->nl_u.ip4_u, sizeof(fl1->nl_u.ip4_u)) == 0 && fl1->oif