On 18 January 2018 at 16:29, Guillaume Nault <g.na...@alphalink.fr> wrote: > On Thu, Jan 18, 2018 at 03:40:52PM +0000, James Chapman wrote: >> On 18 January 2018 at 15:18, Guillaume Nault <g.na...@alphalink.fr> wrote: >> > On Wed, Jan 17, 2018 at 02:25:38PM -0500, David Miller wrote: >> >> If all else was equal, even though it doesn't make much sense to KCM >> >> attach L2TP sockets to KCM, I would suggest to change L2TP to store >> >> it's private stuff elsewhere. >> >> >> >> But that is not the case. Anything using the generic UDP >> >> encapsulation layer is going to make use of sk->sk_user_data like this >> >> (see setup_udp_tunnel_sock). >> >> >> > Most UDP encapsulations only use kernel sockets though. It seems that >> > only L2TP and GTP use setup_udp_tunnel_sock() with userpsace sockets. >> > So it might be feasible to restrict usage of sk_user_data to kernel >> > sockets only. >> > >> > For L2TP, we probably can adapt l2tp_sock_to_tunnel() so that it does >> > a lookup in a hashtable indexed by the socket pointer, rather than >> > dereferencing sk_user_data. That doesn't look very satisfying to me, >> > but that's the only way I found so far. >> >> L2TP needs a way to get at its local data from the socket in the data path. >> > Did I miss something? On xmit, the session is provided by l2tp_ppp or > l2tp_eth, which is enough to get access to the parent tunnel. > For reception, l2tp_udp_encap_recv() receives the socket pointer as > parameter and could get enough information from the headers to retrieve the > tunnel structure anymay (l2tp_ip and l2tp_ip6 use the headers).
It's the receive side I was thinking about. It would be a little more involved to derive the tunnel and session from the packet with UDP since we'd have to handle L2TPv2 and L2TPv3.
