Re: Should sys_unmount() FOLLOW?

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost> wrote:

> > 1) remove FOLLOW flag in sys_unmount(). After all, unless the -R flag is
> > given, umount(8) should have resolved the patch before calling
> > unmount(2).
> 
> Did you try -- last time I tried a forced unmount with NFS server down
> it didn't work even with root being a directory because the namei() call
> would hang in VOP_LOOKUP().  Does it work these days?

As noted in my previous message, yes it works fine in the normal case
where the root is a directory. Well, except if you already had a process
stuck trying to talk to the NFS server (wchan nfscn2), in that case,
umount -f does not really try to unmount as it is stuck awaiting for a
vnode lock (wchan tstile).

I tested removing the FOLLOW flag in sys_unmount(), and it solves my bug
if I use umount -f -R (with the same exception as in the normal case: no
process already in nfscn2). We do not seem to loose functionnality, as
umount(8) without -R already resolves symlinks. In fact the changes
improves umount -R behavior, as the kernel will not perform the symlink
resolution that umount(8) was instructed to skip.

Is there any reason to not commit the change below?

Index: sys/kern/vfs_syscalls.c
===================================================================
RCS file: /cvsroot/src/sys/kern/vfs_syscalls.c,v
retrieving revision 1.490
diff -U 4 -r1.490 vfs_syscalls.c
--- sys/kern/vfs_syscalls.c     25 Jul 2014 16:28:12 -0000      1.490
+++ sys/kern/vfs_syscalls.c     24 Nov 2014 05:04:54 -0000
@@ -573,9 +573,9 @@
        if (error) {
                return error;
        }
 
-       NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF | TRYEMULROOT, pb);
+       NDINIT(&nd, LOOKUP, LOCKLEAF | TRYEMULROOT, pb);
        if ((error = namei(&nd)) != 0) {
                pathbuf_destroy(pb);
                return error;
        }


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost