[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1313754853.2814.8.camel@deadeye>
Date: Fri, 19 Aug 2011 12:54:13 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Changli Gao <xiaosuo@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <eric.dumazet@...il.com>,
Tom Herbert <therbert@...gle.com>, netdev@...r.kernel.org
Subject: Re: net: rps: support 802.1Q
On Fri, 2011-08-19 at 13:05 +0800, Changli Gao wrote:
> For the 802.1Q packets, if the NIC doesn't support hw-accel-vlan-rx, RPS
> won't inspect the internal 4 tuples to generate skb->rxhash, so this kind
> of traffic can't get any benefit from RPS.
>
> This patch adds the support for 802.1Q to RPS.
[...]
> @@ -2565,6 +2566,13 @@ again:
> addr2 = (__force u32) ip6->daddr.s6_addr32[3];
> nhoff += 40;
> break;
> + case __constant_htons(ETH_P_8021Q):
> + if (!pskb_may_pull(skb, sizeof(*vlan) + nhoff))
> + goto done;
> + vlan = (const struct vlan_hdr *) (skb->data + nhoff);
> + proto = vlan->h_vlan_encapsulated_proto;
> + nhoff += sizeof(*vlan);
> + goto again;
> default:
> goto done;
> }
Should this really be reading an unlimited number of tags? What if an
attacker starts sending packets full of VLAN tags? Since this runs
before netfilter, there would be no way to prevent those packets burning
our CPU time. And if there are legitimately multiple VLAN tags, they
presumably won't all have the 802.1q Ethertype.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists