In message <20030220222404.B11525@sfgoth.com>,Mitchell Blank Jr writes:
>Hmmmm.. I guess we've just been getting lucky before in that case - we've
>always just left the ATM_SKB() stuff in there.
i think fortunate might be a better word. comparing the two:
struct atm_skb_data {
struct atm_vcc *vcc;
int iovcnt;
unsigned long atm_options;
};
struct inet_skb_parm
{
struct ip_options {
__u32 faddr;
unsigned char optlen;
unsigned char srr;
unsigned char rr;
unsigned char ts;
...
}
surprising you only run into trouble on some 64bit platforms. at this
point the atm_vcc* overlaps with optlen and chaos ensues. on a somewhat
related note, i believe iovcnt is probably obselete. skb's support
scatter/gather.
>Chas - I guess you should just do a memset(skb->cb, 0, sizeof(skb->cb))
>just before the netif_rx() in {clip,lec,mpc}.c and before the ppp_input()
>in pppoatm.c to make sure it's zeroed correctly.
this is one option. the other would be to clone the skb and pass the
clone to the ip layer. the last option, and the one i prefer, would
be to make the atm drivers not modify skb->cb (or reset it) when passing
up the skb. the atm socket layer doesnt rely on it, and it would keep
the 'extra' processing to a minimum.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Feb 23 2003 - 22:00:34 EST