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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
