On Mon, Oct 05, 2020 at 09:57:47PM +0800, Ka-Cheong Poon wrote: > > > It is a kernel module. Which FD are you referring to? It is > > > unclear why a kernel module must associate itself with a user > > > space FD. Is there a particular reason that rdma_create_id() > > > needs to behave differently than sock_create_kern() in this > > > regard? > > > > Somehow the kernel module has to be commanded to use this namespace, > > and generally I expect that command to be connected to FD. > > > It is an unnecessary restriction on what a kernel module > can do. Is it a problem if a kernel module initiates its > own RDMA connection for doing various stuff in a namespace? Yes, someone has to apply policy to authorize this. Kernel modules randomly running around using security objects is not OK. Kernel modules should not be doing networking unless commanded to by userspace. > Any kernel module can initiate a TCP connection to do various > stuff without worrying about namespace deletion problem. It > does not cause a problem AFAICT. If the module needs to make > sure that the namespace does not go away, it can add its own > reference. Is there a particular reason that RDMA subsystem > needs to behave differently? We don't have those kinds of ULPs. > For scalability and namespace separation reasons as cma_wq is > single threaded. For example, there can be many work to be done > in one namespace. But this should not have an adverse effect on > other namespaces (as long as there are resources available). This is a design issue of the cma_wq, it can be reworked to not need single threaded, nothing to do with namespaces Jason
