Re: [PATCH 0/2] nfsd: add a usermodehelper upcall for client id tracking

["bfields@fieldses.org" <bfields@fieldses.org>]

On Mon, Oct 01, 2012 at 06:05:57PM +0400, Stanislav Kinsbursky wrote:
> 01.10.2012 15:51, Jeff Layton пишет:
> >- Do we need to switch to a different mount namespace somehow based on
> >   the net namespace? Eventually we want to allow nfsd to run in a
> >   container. At some point we'll need a mechanism to ensure that the
> >   upcall runs within the correct container. Stanislav, I'd appreciate
> >   your input here...
> 
> Hello, Jeff.
> As far as I can see - yes, we have to switch to desired mount
> namespace in kernel (because we can't do this in user namespace).
> Moreover, for NFSd mount namespace looks even more important than
> net namespace. I.e. we can't share one NFSd between mount namespaces
> (at least, I don't understand how to do this safely).
> So, if we are going to have NFSd per container, we have to tie NFSd
> and mount namespace somehow.
> Having one NFSd for more than one network namespace looks feasible.
> But we have some races with creation and destruction of service
> per-net transports, and Bruce was suggesting to think about maybe we
> can just simplify all that stuff and create service per network
> namespace.
> 
> BTW, is it possible to split service (trasports, etc.) and it's
> "executors" (kernel threads)? If we could do it, then it would be
> really easy to create as many services (with it's unique namespaces
> combination) as required and teach "executors" to switch to desired
> namespaces while handling service requests.

I'm sure it is possible, and would be more efficient than requiring
(number of containers) * (number of threads per container) threads.

But I think it's also a little more complicated to do, and that to start
off we'd be better off just keeping the services entirely separate.

--b.