netdev - Re: [PATCH v4 net-next 2/2] tc: add 'needs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <552C65F1.8010402@plumgrid.com>
Date:	Mon, 13 Apr 2015 17:57:21 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	Cong Wang <cwang@...pensource.com>,
	Daniel Borkmann <daniel@...earbox.net>
CC:	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Thomas Graf <tgraf@...g.ch>, Jiri Pirko <jiri@...nulli.us>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v4 net-next 2/2] tc: add 'needs_l2' flag to ingress qdisc

On 4/13/15 3:44 PM, Cong Wang wrote:
>
> My suggestion is fairly simple: move skb_pull() out of eth_type_trans()
> and move it to netif_receive_skb(), it apparently needs much more work
> but it worth the effort. This would eliminate the skb_push() in mirred
> and in ifb too, dev_forward_skb() would benefit too.

wow. That would be massive. We're talking months worth of work here.
Though theoretically it's possible, we'd still need a flag to preserve
compatibility with user space and to be able to roll such monster step
by step. Also non-eth devices are calling into netif_receive_skb(). Just
thinking about all corner cases of such move makes me very skeptical
that we can pull it off. In general we don't care about out of tree
drivers, but changing eth_type_trans() this way is really scary.
I'd rather keep things simple which is this patch.
--
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