> On Oct 9, 2020, at 11:34 AM, Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Fri, Oct 09, 2020 at 11:27:44AM -0400, Chuck Lever wrote: > >> Therefore I think the approach is going to be "one RDS listener per >> net namespace". The problem Ka-Cheong is trying to address is how to >> manage the destruction of a listener-namespace pair. The extra >> reference count on the cm_id is pinning the namespace so it cannot >> be destroyed. > > I really don't think this idea of just loading a kernel module and it > immediately creates a network visibile listening socket in every > namespace is very good. > >> Understood, but it doesn't seem like there is enough useful overlap >> between the NFS and RDS usage scenarios. With NFS, I would expect >> an explicit listener shutdown from userland prior to namespace >> destruction. > > Yes, because namespaces are fundamentally supposed to be anchored in > the processes inside the namespace. Aye, the container model. > Having the kernel jump in and start opening holes as soon as a > namespace is created is just wrong. > > At a bare minimum the listener should not exist until something in the > namespace is willing to work with RDS. I was thinking that too, but I'm not sure if that change would have ramifications to existing RDS applications. There's quite a bit of legacy to deal with. An alternative would be to add a user daemon to RDS to manage the listener lifecycle, rather than having the endpoint created by module load. That might help the listener-namespace destruction issue, and should be entirely application-transparent. -- Chuck Lever chucklever@xxxxxxxxx
