netdev - Re: [PATCH net-next 0/5] udp: Flow dissection for tunnels

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: <20161013.151700.1071876162706356206.davem@davemloft.net>
Date:   Thu, 13 Oct 2016 15:17:00 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     tom@...bertland.com
Cc:     netdev@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH net-next 0/5] udp: Flow dissection for tunnels

From: Tom Herbert <tom@...bertland.com>
Date: Wed, 12 Oct 2016 16:25:42 -0700

> Since performing a UDP lookup on every packet might be expensive I
> added a static key check to bypass the lookup if there are no
> sockets with flow_dissect set. I should mention that doing the
> lookup wasn't particularly a big hit anyway.

I think this new static key is unnecessary, as it is equivalent
to: (udp_encap_needed + udpv6_encap_needed)

This socket lookup is very heavy handed, and I realize that you
need this because we no longer store the encapsulation socket in
skb->sk these days.

Can you talk about the various code paths that lead into the
flow dissector and why the UDP socket lookup is needed?  Maybe
we can propagate it another way, at least on TX.

Thanks.