Re: [PATCH net-next] kcm: do not attach sockets if sk_user_data is already used

On 18 January 2018 at 16:29, Guillaume Nault [off-list ref] wrote:

On Thu, Jan 18, 2018 at 03:40:52PM +0000, James Chapman wrote:

quoted

On 18 January 2018 at 15:18, Guillaume Nault [off-list ref] wrote:

quoted

On Wed, Jan 17, 2018 at 02:25:38PM -0500, David Miller wrote:

quoted

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.