> -----Original Message----- > From: David Miller [mailto:davem@xxxxxxxxxxxxx] > Sent: Friday, December 31, 2010 10:46 PM > To: stephen.hemminger@xxxxxxxxxx > Cc: Winkler, Tomas; shemminger@xxxxxxxxxx; johannes@xxxxxxxxxxxxxxxx; > netdev@xxxxxxxxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx > Subject: Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged > skbs > > From: Stephen Hemminger <stephen.hemminger@xxxxxxxxxx> > Date: Thu, 30 Dec 2010 15:06:16 -0800 > > > Although copy is slower for large packets, this is a non performance > > path. The code in question is for bridged multicast Ipv6 ICMP > > packets. This case is so uncritical it could be done in BASIC and no > > one could possibly care! > > I still think we should be judicious and keep using skb_clone() here. > > Simply combine the two pskb_may_pull() calls into one on "skb2" after > the clone and before the blind __skb_pull() call. Then add a error > path "out:" called "out_nopush:" for the error path to goto. > > Also, I think the "+ 1" in the ipv6 stack code comes from the fact that > the parsing loop can "peek" into the next header's byte to see the type. > And I really don't think it's relevant here. > > Also, all of these "x_header + ... + 1 - skb->data" factors are > irrelevent and shouldn't be used. Just pass "offset + sizeof(*icmp6h)" > to pskb_may_pull(). Sounds reasonable but maybe we shall pass offset + sizeof(struct mld_msg) as *icmp6h is casted to this struct mld_mca is accessed. struct mld_msg { struct icmp6hdr mld_hdr; struct in6_addr mld_mca; }; Thanks Tomas --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
