[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6F5C1D715B2DA5498A628E6B9C124F04019BF9E48E@hasmsx504.ger.corp.intel.com>
Date: Mon, 3 Jan 2011 12:17:57 +0200
From: "Winkler, Tomas" <tomas.winkler@...el.com>
To: Johannes Berg <johannes@...solutions.net>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Stephen Hemminger <shemminger@...tta.com>
Subject: RE: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
> -----Original Message-----
> From: Johannes Berg [mailto:johannes@...solutions.net]
> Sent: Monday, January 03, 2011 12:04 PM
> To: Winkler, Tomas
> Cc: davem@...emloft.net; netdev@...r.kernel.org; Stephen Hemminger
> Subject: RE: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
>
> On Mon, 2011-01-03 at 11:43 +0200, Winkler, Tomas wrote:
>
> > > > - struct mld_msg *mld = (struct mld_msg *)icmp6h;
> > > > + struct mld_msg *mld;
> > > > + if (!pskb_may_pull(skb2, sizeof(*mld))) {
> > > > + err = -EINVAL;
> > > > + goto out;
> > > > + }
> > > > + mld = (struct mld_msg *)icmp6h;
> > >
> > > This (and the second instance) is incorrect afaict -- the pointer
> > > "icmp6h" should be reloaded after the pskb_may_pull(), no?
> >
> > mld_msg is bigger than icmp6h by sizeof(in6_addr) so we have to try pull
> again a bigger chunk.
>
> Right, I know, the pskb_may_pull() is needed, but I believe you need to
> re-calculate icmp6h here.
You are right, it can be moved to new memory buffer.
Probably something like that will do it:
if (!pskb_may_pull(skb2, sizeof(*mld))) {
err = -EINVAL;
goto out;
}
mld = (struct mld_msg *)skb_transport_header(skb2)
>
> > > Also, the "out_nopush" thing is pointless since the push is completely
> > > unnecessary as "skb2 != skb" is always true.
> >
> > You are right if skb_clone doesn't return the same pointer then yes.
> > Shame, but I'm not a sbk expert. I'm diving into it now.
>
> I'm pretty sure it's guaranteed to return a new pointer.
Right, it either returns skb + 1 or new one from the cache. We can drop the nopush section.
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.
Powered by blists - more mailing lists