[lkml]   [2003]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ATM] who 'owns' the skb created by drivers/atm?
In message <>,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

>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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.046 / U:12.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site