In message <[EMAIL PROTECTED]>, Malcolm Beattie writes:
> I sent this to linux-kernel 10 days ago but got zero responses so I'll
> try here in case I get luckier.
I don't recall seeing your message from 10 days ago. Maybe it didn't get to
others as well.
> I'm writing a little "fake" filesystem module which, when mounted on a
> mountpoint, makes the root of the new filesystem be a "magic" symlink.
> It all works fine except that the filesystem won't unmount. strace
> shows that oldumount is returning EINVAL. What the "magic symlink"
> does isn't important here and the following cut-down version displays
> the same problem. Is it something to do with the fact that the core fs
> code expects the root of the new filesystem to be an ordinary
> directory or am I missing something else? Here's the cut-down module
> which simply makes follow_link appear to be your cwd. You can compile
> (under 2.2 or 2.3, though 2.3 is untested) by
>
> cc -c -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe
>-fno-strength-reduce -m486 -DCPU=486 -DMODULE -DMODVERSIONS -include
>/usr/src/linux/include/linux/modversions.h -I/usr/src/linux/include nullfs.c
>
> (modifying arch-specific options as necessary) and then doing
> # insmod ./nullfs.o
> # mkdir /tmp/nullcwd
> # mount -t null none /tmp/nullcwd
> # ls -l /tmp/nullcwd
> lrwxrwxrwx 1 root root 0 Nov 30 12:21 /tmp/nullcwd -> foo
> # ls -l /tmp/nullcwd/
> ...listing of your current working directory...
> # umount /tmp/nullcwd
> umount: none: not found
> umount: /tmp/foo: not mounted
> How can I get it to umount properly?
I've not looked at your code, but you might want to see what I do in my
wrapfs/lofs during mount and unmount. Usually the main reason why something
won't unmount is that you're holding some resources (inodes, dentries, etc.)
in which case you get EBUSY.
If you're getting EINVAL, the question is where? Is your code being invoked
at all, or is the VFS giving this EINVAL. If your code isn't called, then
search the VFS (starting w/ do_umount) to find what code path could return
you an EINVAL. I personally found out that it's faster (and more fun :-) to
debug VFS code myself by sticking printf's at certain places and building a
test kernel with that.
BTW, just to avoid any potential problems, mount w/ the real mnt point name
instead of 'none'.
Erez.
