From: Jay Vosburgh <fubar@us...> - 2005-07-14 00:42:00
Stephen J. Bevan <stephen@...> wrote:
>While using a backport of the 2.4.31 bonding code in a 2.4.18 kernel
Ok, I won't.
>Looking at the code this is due to the use of __ntohs_lacpdu in the
>context of bond_3ad_rx_indication in the context of bond_3ad_lacpdu_recv.
>In this context __ntohs_lacpdu is byte-swapping the data directly in a
>skb->data without taking into account that the skb may be shared --
>which it is when traffic is being sniffed.
Yah, I'd never noticed this; I end up ususally tcpdumping on a
ppc64, which doesn't show the problem.
>My non-hacky solution would be to avoid the problem by changing the
>code that bond_3ad_rx_indication calls so that it doesn't assume that
>various fields in the lacpdu structure are in host-order and instead
>uses ntohs where necessary. However, that touches quite a few
>functions and it may not be the way you want it fixed, if indeed you
>want it fixed at all since the problem is rather obscure. Hence I'm
>not attaching a patch that does this. If you want one, let me know.
In looking at it briefly, I'm not sure if it's better to ntohs
stuff as needed, or build a parallel structure full of host-ized values
to pass down with the lacpdu into ad_rx_machine() from
bond_3ad_rx_indication. Probably ntohs as needed, since that "goes
away" on network byte order systems. Just need to check that everything
from ad_rx_machine on down is an isolated area.
I also noticed some minor yuckage in __update_lacpdu_from_port;
it calls __ntohs_lacpdu to translate the template lacpdu from host to
network byte order. It's annoying in that it depends on the fact that
ntohs and htons are effectively interchangeable, which is probably true
on any rational architecture, but it Really Ought To Be htons.
If you've got a patch, by all means share and enjoy.
-Jay Vosburgh, IBM Linux Technology Center, fubar@...