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).
l2tp_ppp also uses sk_user_data for its PPPOX sockets, but we probably can handle this case more easily.
