On Wed, Oct 07, 2020 at 04:38:45PM +0800, Ka-Cheong Poon wrote: > On 10/6/20 8:46 PM, Jason Gunthorpe wrote: > > On Tue, Oct 06, 2020 at 05:36:32PM +0800, Ka-Cheong Poon wrote: > > > > > > > > Kernel modules should not be doing networking unless commanded to by > > > > > > userspace. > > > > > > > > > > It is still not clear why this is an issue with RDMA > > > > > connection, but not with general kernel socket. It is > > > > > not random networking. There is a purpose. > > > > > > > > It is a problem with sockets too, how do the socket users trigger > > > > their socket usages? AFAIK all cases originate with userspace > > > > > > A user starts a namespace. The module is loaded for servicing > > > requests. The module starts a listener. The user deletes > > > the namespace. This scenario will have everything cleaned up > > > properly if the listener is a kernel socket. This is not the > > > case with RDMA. > > > > Please point to reputable code in upstream doing this > > > It is not clear what "reputable" here really means. If it just > means something in kernel, then nearly all, if not all, Internet > protocols code in kernel create a control kernel socket for every > network namespaces. That socket is deleted in the per namespace > exit function. If it explicitly means listening socket, AFS and > TIPC in kernel do that for every namespaces. That socket is > deleted in the per namespace exit function. AFS and TIPC are not exactly well reviewed mainstream areas. > It is very common for a network protocol to have something like > this for protocol processing. It is not clear why RDMA subsystem > behaves differently and forbids this common practice. Could you > please elaborate the issues this practice has such that the RDMA > subsystem cannot support it? The kernel should not have rouge listening sockets just because a model is loaded. Creation if listening kernel side sockets should be triggered by userspace. Jason
