From: Guillaume Chazarain [EMAIL PROTECTED]
Date: Wed, 19 Jul 2006 14:35:15 +0200
Herbert Xu wrote :
Probably. Patches are welcome :)
Here are they, in both case I checked that the stuff to clear
was not already cleared, but I could not produce any misbehavior
by writing random junk instead
Herbert Xu wrote :
Probably. Patches are welcome :)
Here are they, in both case I checked that the stuff to clear
was not already cleared, but I could not produce any misbehavior
by writing random junk instead of clearing the data. All my tests
were on the loopback using UML.
For IPv4, the
chas williams - CONTRACTOR wrote:
why does the input side of the ip layer believe the cb contains valid
data? it should zero the contents of the cb, or just fill in the cb
correctly when the packet arrives at its doorstop.
Why not clearing the whole IPCB(skb) instead of
just IPCB(skb)-opts?
On Tue, Jul 18, 2006 at 08:19:34PM +0200, Guillaume Chazarain wrote:
Why not clearing the whole IPCB(skb) instead of
just IPCB(skb)-opts? that would also clear
IPCB(skb)-flags.
I agree, we should clear the whole IPCB.
And, does not ipv6 need the same treatment with
IP6CB?
Probably.
In message [EMAIL PROTECTED],David Miller writes:
From: Herbert Xu [EMAIL PROTECTED]
At least this lets us get rid of a few other memsets :)
Applied, good spotting :-) I remember when we added those
things.
But I'm beginning to think that the onus of this may in fact fall upon
the devices, in
On Sat, Jul 15, 2006 at 06:12:22PM -0700, David Miller wrote:
But I'm beginning to think that the onus of this may in fact fall upon
the devices, in fact. Loopback is one of the few devices where the
control block might not be cleared out, due to uses in the output
path. Devices
From: Herbert Xu [EMAIL PROTECTED]
Date: Mon, 17 Jul 2006 08:03:50 +1000
The thing is qdiscs using cb means that this method of clearing cb
before netif_rx doesn't work anymore.
In particular, even if loopback clears cb before calling netif_rx,
some qdisc could come along between netif_rx
From: chas williams - CONTRACTOR [EMAIL PROTECTED]
Date: Sun, 16 Jul 2006 07:20:35 -0400
why does the input side of the ip layer believe the cb contains valid
data? it should zero the contents of the cb, or just fill in the cb
correctly when the packet arrives at its doorstop.
Yes, that's
David Miller [EMAIL PROTECTED] wrote:
Thank goodness this thing is only 3-words in size, this is going to
run on every single IPv4 packet received by the system. :-/
At least this lets us get rid of a few other memsets :)
[IPV4]: Get rid of redundant IPCB-opts initialisation
Now that we
From: Herbert Xu [EMAIL PROTECTED]
Date: Sat, 15 Jul 2006 23:28:34 +1000
At least this lets us get rid of a few other memsets :)
[IPV4]: Get rid of redundant IPCB-opts initialisation
Now that we always zero the IPCB-opts in ip_rcv, it is no longer
necessary to do so before calling
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Sat, 15 Jul 2006 08:50:58 -0700
Since skb-cb is aligned, we could optimize the initialization
slightly by just using:
*(unsigned long *)skb-cb = 0;
Well, that depends upon two things.
1) How much of the ip_options really needs to be zero'd
when data arrives at IP through loopback (and possibly other devices).
So the field needs to be cleared before it confuses the route code.
This was seen when running netem over loopback, but there are probably
other device cases. Maybe this should go into stable?
Signed-off-by: Stephen Hemminger
12 matches
Mail list logo
