How to unmount mounts corresponding to super_block structure?

How to unmount mounts corresponding to super_block structure?

[Anatol Pomozov]

Hi,

I am working on fuse changes to cleanup (unmount) mountpoint on
filesystem daemon crash. Currently unmounting is done as a part of
user-space daemon shutdown hook, but in case if the daemon gets
SIGKILL or SIGSEGV the hook is not executed and mountpoint is left
unmounted. I want to move the cleanup code to kernel.

Now I need to call umount() from inside kernel code (from
fuse_dev_release() in fs/fuse/dev.c). I see do_umount() function in
fs/namespace.c it sounds like what I need. Unfortunately this function
accepts struct mount and all I have is super_block structure.

What I am trying to do is to iterate current filesystem namespace and
find mountpoints that correspond to super_block. Namespace can have
multiple corresponding mountpoints in case of bind mounts. Here is
code that seems to work fine http://pastebin.com/xLECPGa4 . Now I am
trying to understand what synchronization is required for this code.
It looks like access to nsproxy->mnt_ns->list should be done with
namespace_sem held. Unfortunately that semaphore is internal to
fs/namespace.c. It is not clear for me how I suppose to iterate the
mount list.

Is there any advice/code example how to umount() mountpoints for a
given super_block?

Re: How to unmount mounts corresponding to super_block structure?

[Al Viro]

On Tue, Feb 26, 2013 at 10:35:12PM -0800, Anatol Pomozov wrote:

> What I am trying to do is to iterate current filesystem namespace and
> find mountpoints that correspond to super_block. Namespace can have
> multiple corresponding mountpoints in case of bind mounts. Here is
> code that seems to work fine http://pastebin.com/xLECPGa4 . Now I am
> trying to understand what synchronization is required for this code.
> It looks like access to nsproxy->mnt_ns->list should be done with
> namespace_sem held. Unfortunately that semaphore is internal to
> fs/namespace.c. It is not clear for me how I suppose to iterate the
> mount list.
> 
> Is there any advice/code example how to umount() mountpoints for a
> given super_block?

Simple: don't.  This is fundamentally wrong thing to do.  Not to mention
anything else, there may be more than one namespace out there.  This
operation makes no sense.

Incidentally, anybody adding includes of fs/mount.h would better be ready
to explain {What,Why}TF is being done.  There's a damn good reason why
this list is outside of public struct vfsmount...

Re: How to unmount mounts corresponding to super_block structure?

[Anatol Pomozov]

Hi

On Tue, Feb 26, 2013 at 10:56 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> Simple: don't.  This is fundamentally wrong thing to do.  Not to mention
> anything else, there may be more than one namespace out there.  This
> operation makes no sense.

Yes I understand that there can be multiple namespaces. And I am fine
with unmounting only in the current namespace. It is actually how
libfuse currently implemented - it calls umount() on the mount point
path, so it leaves 1) bind mounts 2) mounts in other namespaces
untouched.

Another ugly-but-working solution for fuse would be pass mountpoint
path as a mount option and store it to super_block. Then in
fuse_dev_release() call sys_umount(). But I am looking if there are
any cleaner solutions.

Re: How to unmount mounts corresponding to super_block structure?

[Al Viro]

On Tue, Feb 26, 2013 at 11:19:30PM -0800, Anatol Pomozov wrote:
> Hi
> 
> On Tue, Feb 26, 2013 at 10:56 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > Simple: don't.  This is fundamentally wrong thing to do.  Not to mention
> > anything else, there may be more than one namespace out there.  This
> > operation makes no sense.
> 
> Yes I understand that there can be multiple namespaces. And I am fine
> with unmounting only in the current namespace. It is actually how
> libfuse currently implemented - it calls umount() on the mount point
> path, so it leaves 1) bind mounts 2) mounts in other namespaces
> untouched.
>
> Another ugly-but-working solution for fuse would be pass mountpoint
> path as a mount option and store it to super_block. Then in
> fuse_dev_release() call sys_umount().

Observe mount --move...  There is no promise that it'll stay mounted where
it used to be.  BTW, what about somebody having cloned the entire namespace?
Or spread the sucker via shared subtree stuff to another namespace, later
remounted private, etc.

"All places where the filesystem is mounted" is about as good a notion as
"all pathnames of a file".  Sorry.

	Besides, I _really_ doubt that it's a sane idea to start with; consider
something like mount --bind empty_directory <something I really want overmounted
and not accessible>.  Having it suddenly exposed without your explicit action
is not a good thing.  As the matter of fact, something very similar had been
outright NAKed by Linus and I agree with his arguments...