Re: [PATCH 00/11] [RFC] repair net namespace damage to rpc_pipefs

[Al Viro <viro@ZenIV.linux.org.uk>]

On Mon, Dec 02, 2013 at 08:44:25AM -0500, Trond Myklebust wrote:

> > I'll have to let the net namespace folks chime in for that, as far as
> > I'm concerned it's a featured better config'ed off.  If they can't come
> > up with anything better the procfs hack above would be it.
> 
> The lifetime of the kernel mount only needs to match that of the rpc_client, since each rpc_client is associated to a single net namespace, and each net namespace is in a 1-1 relationship with an rpc_pipefs super block.
> 
> IOW: move the kernel mount/umount back to the rpc_client create/destroy methods and all should be well.

Hmm...  I'm looking through rpc_pipe.c and there are some fun issues in there:
	* ->kill_sb() *is* called after rpc_fill_super() failures.  It's
not ->put_super() (and even ->put_super() would've been called for failures
past setting ->s_root).  With ->s_fs_info set only on success, it means
that rpc_kill_sb() will just oops after such failure exits.
	* just what is
        if (sn->pipefs_sb != sb) {
                mutex_unlock(&sn->pipefs_sb_lock);
                goto out;
        }
        sn->pipefs_sb = NULL;
about?  In which scenario is it not equal to ->pipefs_sb?  When said
->pipefs_sb is NULL?  But that, AFAICS, can happen only on cleanup after
failing rpc_fill_super(), in which case we won't get that sn thing in
the first place (in fact, we'll oops trying to get it).

Trond, am I right interpreting you as "that filesystem has non-empty
contents only when there is at least one rpc_client in that netns;
after rpc_client removal there won't be any accesses to data structures
associated with it (due to rpc_close_pipes() and friends, presumably),
so there won't be any need to keep netns alive after that"?

If so and if rpc_client really can't outlive netns, then yes, having each 
of them hold an internal vfsmount reference pinning rpc_pipefs down would
suffice.