NetBSD Problem Report #50664
From www@NetBSD.org Sun Jan 17 04:40:59 2016
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 92DE17ACAD
for <gnats-bugs@gnats.NetBSD.org>; Sun, 17 Jan 2016 04:40:59 +0000 (UTC)
Message-Id: <20160117044058.931287ACC7@mollari.NetBSD.org>
Date: Sun, 17 Jan 2016 04:40:58 +0000 (UTC)
From: marcotte@panix.com
Reply-To: marcotte@panix.com
To: gnats-bugs@NetBSD.org
Subject: "cd .." over NFS/ZFS can panic kernel
X-Send-Pr-Version: www-1.0
>Number: 50664
>Category: kern
>Synopsis: "cd .." over NFS/ZFS can panic kernel
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: hannken
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Jan 17 04:45:01 +0000 2016
>Closed-Date: Thu Jul 14 07:08:47 +0000 2016
>Last-Modified: Thu Jul 14 07:08:47 +0000 2016
>Originator: Brian Marcotte
>Release: 6.1.5
>Organization:
Public Access Networks, Corp.
>Environment:
NetBSD panix1.panix.com 6.1.5 NetBSD 6.1.5 (PANIX-XEN-USER) #0: Tue Oct 27 18:53:48 EDT 2015 root@juggler.panix.com:/misc/obj/misc/devel/netbsd/6.1.5/src/sys/arch/i386/compile/PANIX-XEN-USER i386
>Description:
Where "/net/u" is a ZFS filesystem NFS mounted from another server:
cd /net/u/.zfs/shares
cd ..
causes this panic in 6.1.5:
Reader / writer lock error: rw_vector_enter: locking against myself
lock address : 0x00000000cd3284d4
current cpu : 0
current lwp : 0x00000000c390eaa0
owner/count : 0x00000000c390eaa0 flags : 0x0000000000000004
panic: lock error
cpu0: Begin traceback...
panic(c0393911,c038a362,c036fe68,c03893c3,cd3284d4,0,c390eaa0,cd3284d4,c390eaa4,db34d944) at netbsd:panic+0x18
lockdebug_abort(cd3284d4,c03a6864,c036fe68,c03893c3,db34d984,c01e52b3,8200,db34d9bc,c0233fb8,cd328430) at netbsd:lockdebug_abort+0x2f
rw_abort.clone.1(8200,db34d9bc,c0233fb8,cd328430,db34da44,1,3,1,c390eaa4,c390eaa0) at netbsd:rw_abort.clone.1+0x32
rw_vector_enter(cd3284d4,1,1,cd328430,20000,db34d9c4,c032eeea,db34d9b4,0,0) at netbsd:rw_vector_enter+0x1a3
genfs_lock(db34d9b4,0,0,c037a134,cd328430,2,cd328430,db34d9e4,c0325c76,cd328430) at netbsd:genfs_lock+0xae
VOP_LOCK(cd328430,2,2,0,8200,db34da44,db34daf8,c0235677,cd328430,20002) at netbsd:VOP_LOCK+0x4a
vn_lock(cd328430,20002,ca859900,db34da08,c0338cf2,6,c05b7000,db34da48,c011dc1d,cad9ed88) at netbsd:vn_lock+0x76
nfs_lookup(db34db0c,c01d29d4,0,c0379d08,cd328430,db34db58,db34dc7c,cd328430,db34db68,c03172b8) at netbsd:nfs_lookup+0x1207
VOP_LOOKUP(cd328430,db34db58,db34dc7c,0,c037a134,cd328430,ca51d738,db34dc58,db34dc2c,c390eaa0) at netbsd:VOP_LOOKUP+0x50
lookup_once(db34dbfc,db34dbf8,4,21,c3108dc0,cd328430,db34dc1c,db34dcac,c02ff183,ca8336e0) at netbsd:lookup_once+0x178
namei_tryemulroot(0,db34dc58,db34dc7c,20,0,1,ca51d738,db34dca4,c031fa5a,db34dc58) at netbsd:namei_tryemulroot+0x1c6
namei(db34dc58,db34dc98,db34dc98,c6486280,cb38bc00,c3108dc0,0,1,0,1) at netbsd:namei+0x41
chdir_lookup(80dd308,0,db34dcc0,c390eaa0,1a27750b,c390eaa0,c390eaa0,db34dd48,db34dd3c,c02b3f4a) at netbsd:chdir_lookup+0x5a
sys_chdir(c390eaa0,db34dd00,db34dd28,c,8121000,0,db34dd00,ca51d738,2,bb729e87) at netbsd:sys_chdir+0x35
syscall(db34dd48,bb7e00b3,ab,1f,bf7f001f,bb7ea000,0,bf7fe6b4,0,80dd30a) at netbsd:syscall+0xaa
cpu0: End traceback...
NetBSD 7.0 doesn't panic, but the process will wait in "tstile" forever.
>How-To-Repeat:
NFS mount a ZFS filesystem and run the above commands. In our case, the
NFS server is OmniOS, an OpenSolaris derivative.
We can probably provide a couple of virtual hosts for debugging this if
desired.
>Fix:
Unknown
>Release-Note:
>Audit-Trail:
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 11:20:41 +0100
> =
vn_lock(cd328430,20002,ca859900,db34da08,c0338cf2,6,c05b7000,db34da48,c011=
dc1d,cad9ed88) at netbsd:vn_lock+0x76
> =
nfs_lookup(db34db0c,c01d29d4,0,c0379d08,cd328430,db34db58,db34dc7c,cd32843=
0,db34db68,c03172b8) at netbsd:nfs_lookup+0x1207
> =
VOP_LOOKUP(cd328430,db34db58,db34dc7c,0,c037a134,cd328430,ca51d738,db34dc5=
8,db34dc2c,c390eaa0) at netbsd:VOP_LOOKUP+0x50
Did you build the kernel with =E2=80=98makeoptions DEBUG=3D=E2=80=9C-g=E2=80=
=9D=E2=80=99?
If you did, what is the corresponding source of nfs_lookup+0x1207?
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Brian Marcotte <marcotte@panix.com>
To: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 06:33:49 -0500
> If you did, what is the corresponding source of nfs_lookup+0x1207?
(gdb) list *nfs_lookup+0x1207
0xc023ffc7 is in nfs_lookup (/misc/devel/netbsd/6.1.5/src/sys/nfs/nfs_vnops.c:866).
861 if ((flags & ISDOTDOT) != 0) {
862 VOP_UNLOCK(dvp);
863 }
864 error = vn_lock(newvp, LK_EXCLUSIVE);
865 if ((flags & ISDOTDOT) != 0) {
866 vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY);
867 }
868 if (error != 0) {
869 /* newvp has been reclaimed. */
870 vrele(newvp);
Also, if I add DEBUG, DIAGNOSTIC and LOCKDEBUG, the panic looks like this:
panic: kernel diagnostic assertion "dvp != *vpp" failed: file "/misc/devel/netbsd/6.1.5/src/sys/nfs/nfs_vnops.c", line 821
cpu0: Begin traceback...
kern_assert(c03d51d0,c03d5211,c03ec7e0,c03ec70c,335,0,c03734f3,c2b2ca6c,2,caba6c74) at netbsd:kern_assert+0x23
nfs_lookup(caba6adc,c2b2c798,caba6c74,caba6c74,caba6af4,c0381dc2,c03d01c8,c2b2c798,caba6b2c,caba6c74) at netbsd:nfs_lookup+0x1490
VOP_LOOKUP(c2b2c798,caba6b2c,caba6c74,c2b2c848,1,c2b2c85c,c0d3d6d0,caba6c1c,caba6c50,c0beb2c0) at netbsd:VOP_LOOKUP+0xa8
lookup_once(caba6bdc,caba6bd8,4,c2b2c7ac,caba6b80,c0386603,c0e06da0,0,caba6c50,caba6b74) at netbsd:lookup_once+0x19f
namei_tryemulroot(0,c0b16b40,1,0,c0411830,caba6c50,caba6c74,20,0,0) at netbsd:namei_tryemulroot+0x212
namei(caba6c50,caba6c90,caba6c90,c0e06da8,c0b65c00,c0d56dc0,0,ffffffff,ffffffff,1) at netbsd:namei+0x29
chdir_lookup(8065fb4,0,caba6cb8,c0beb2c0,0,0,c0beb2c0,caba6d48,caba6d3c,c02e55ca) at netbsd:chdir_lookup+0x5a
sys_chdir(c0beb2c0,caba6d00,caba6d28,c029d446,c13e454c,c,c040e2aa,fffffffe,caba6d00,c0d3d6d0) at netbsd:sys_chdir+0x35
syscall(caba6d48,bb5800b3,bb5000ab,bb50001f,bf7f001f,0,0,bf7febd0,0,8065fb4) at netbsd:syscall+0xaa
cpu0: End traceback...
Thanks.
--
- Brian
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@NetBSD.org
Cc: marcotte@panix.com
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 13:21:04 +0100
--Apple-Mail=_7C9C5061-DDD1-47BE-B448-340D916A353D
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
So we are looking up DOTDOT (..) and get DOT (.).
Could you try to dump the file handles from /net/u/.zfs/shares directories?
Compile the little program attached and run it as root.
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
--Apple-Mail=_7C9C5061-DDD1-47BE-B448-340D916A353D
Content-Disposition: attachment;
filename=fh.c
Content-Type: application/octet-stream;
name="fh.c"
Content-Transfer-Encoding: 7bit
#include <sys/types.h>
#include <sys/mount.h>
#include <err.h>
#include <stdio.h>
int
main(int argc, char **argv)
{
int i, p;
size_t fhsz;
uint8_t fhbuf[512];
char *paths[] = {
"/net/.",
"/net/u/.",
"/net/u/.zfs/.",
"/net/u/.zfs/shares/.",
NULL
};
for (i = 0; paths[i] != NULL; i++) {
fhsz = sizeof(fhbuf);
if (getfh(paths[i], &fhbuf[0], &fhsz) != 0)
err(1, "getfh \"%s\"", paths[i]);
printf("\"%s\" -> %zd:", paths[i], fhsz);
for (p = 0; p < fhsz; p++)
printf(" %02x", fhbuf[p]);
printf("\n");
}
return 0;
}
--Apple-Mail=_7C9C5061-DDD1-47BE-B448-340D916A353D--
From: Brian Marcotte <marcotte@panix.com>
To: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 07:39:58 -0500
> Could you try to dump the file handles from /net/u/.zfs/shares directories?
> Compile the little program attached and run it as root.
# ./fh
"/net/." -> 28: 00 8e 00 00 8b 07 00 00 0c 00 00 00 00 63 01 00 c5 6e 7b 02 00 00 00 00 00 00 00 00
"/net/u/." -> 44: 01 0b 00 00 0b 07 00 00 24 00 00 00 43 86 09 3a 08 5b 05 4e 0a 00 04 00 00 00 00 00 2a 49 55 00 0a 00 04 00 00 00 00 00 2a 49 55 00
"/net/u/.zfs/." -> 44: 01 0b 00 00 0b 07 00 00 24 00 00 00 43 86 09 3a 08 5b 05 4e 0a 00 01 00 00 00 00 00 00 00 00 00 0a 00 04 00 00 00 00 00 2a 49 55 00
"/net/u/.zfs/shares/." -> 44: 01 0b 00 00 0b 07 00 00 24 00 00 00 43 86 09 3a 08 5b 05 4e 0a 00 07 00 00 00 00 00 2a 49 55 00 0a 00 04 00 00 00 00 00 2a 49 55 00
--
- Brian
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: Brian Marcotte <marcotte@panix.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 14:11:11 +0100
Good, all directories have different file handles.
Could you add a printf to nfs_cache_enter() to print all nfs nodes
entered into the name cache (not even compile tested here):
--- nfs_vnops.c 12 Aug 2012 12:59:48 -0000 1.293.4.1
+++ nfs_vnops.c 17 Jan 2016 13:06:39 -0000
@@ -280,4 +280,5 @@ nfs_cache_enter(struct vnode *dvp, struc
dnp->n_nctime = dnp->n_vattr->va_mtime;
+printf("enter %p %p \"%.*s\"\n", dvp, vp, cnp->cn_namelen, cnp->cn_nameptr);
cache_enter(dvp, vp, cnp);
}
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Brian Marcotte <marcotte@panix.com>
To: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 08:37:51 -0500
> Could you add a printf to nfs_cache_enter() to print all nfs nodes
> entered into the name cache (not even compile tested here):
Here is some console output with the added printf:
# ls /net/u
# ls /net/u/.zfs
enter 0xc1b39dd0 0xc1b39bc0 ".zfs"
shares snapshot
# ./fh
"/net/." -> 28: 00 8e 00 00 8b 07 00 00 0c 00 00 00 00 63 01 00 c5 6e 7b 02 00 00 00 00 00 00 00 00
"/net/u/." -> 44: 01 0b 00 00 0b 07 00 00 24 00 00 00 43 86 09 3a 08 5b 05 4e 0a 00 04 00 00 00 00 00 2a 49 55 00 0a 00 04 00 00 00 00 00 2a 49 55 00
"/net/u/.zfs/." -> 44: 01 0b 00 00 0b 07 00 00 24 00 00 00 43 86 09 3a 08 5b 05 4e 0a 00 01 00 00 00 00 00 00 00 00 00 0a 00 04 00 00 00 00 00 2a 49 55 00
enter 0xc1b39bc0 0xc1b39a60 "shares"
"/net/u/.zfs/shares/." -> 44: 01 0b 00 00 0b 07 00 00 24 00 00 00 43 86 09 3a 08 5b 05 4e 0a 00 07 00 00 00 00 00 2a 49 55 00 0a 00 04 00 00 00 00 00 2a 49 55 00
# ls -l /net/u
enter 0xc1b39dd0 0xc1b399b0 "1"
enter 0xc1b39dd0 0xc1b39900 "2"
enter 0xc1b39dd0 0xc1b39850 "3"
enter 0xc1b39dd0 0xc1b397a0 "4"
total 2
-rw-r--r-- 1 root wheel 0 Jan 17 08:31 1
-rw-r--r-- 1 root wheel 0 Jan 17 08:31 2
-rw-r--r-- 1 root wheel 0 Jan 17 08:31 3
-rw-r--r-- 1 root wheel 0 Jan 17 08:31 4
# ls /net/u/.zfs/..
enter 0xc1b39dd0 0xc1b39bc0 ".zfs"
enter 0xc1b39bc0 0xc1b39dd0 ".."
1 2 3 4
# ls /net/u/.zfs/shares/..
enter 0xc1b39a60 0xc1b39a60 ".."
panic: kernel diagnostic assertion "dvp != *vpp" failed: file "/misc/devel/netbsd/6.1.5/src/sys/nfs/nfs_vnops.c", line 824
[...]
--
- Brian
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: Brian Marcotte <marcotte@panix.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 15:33:13 +0100
Fine.
We have =E2=80=9C/net/u=E2=80=9D as 0xc1b39dd0, =E2=80=9C.zfs=E2=80=9D =
as 0xc1b39bc0 and =E2=80=9Cshares=E2=80=9D as 0xc1b39a60.
Now we enter (0xc1b39a60 0xc1b39a60 "..=E2=80=9D), this enters =
"shares=E2=80=9D as its own parent.
Could you add a panic() after the printf so we get the backtrace when =
things go wrong:
+printf("enter %p %p \"%.*s\"\n", dvp, vp, cnp->cn_namelen, =
cnp->cn_nameptr);
+if (dvp =3D=3D vp && cnp->cn_namelen =3D=3D 2 && =
strncmp(cnp->cn_nameptr, =E2=80=9C..=E2=80=9D, 2) =3D=3D 0)
+ panic(=E2=80=9Cbad parent=E2=80=9D);
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)=
From: Brian Marcotte <marcotte@panix.com>
To: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 15:24:10 -0500
> Could you add a panic() after the printf so we get the backtrace when =
> things go wrong:
enter 0xc1b397a0 0xc1b397a0 ".."
panic: bad parent
cpu0: Begin traceback...
panic(c03ef205,c0405d48,2,2,c0d59400,c1b397a0,0,cab32930,c0d3f924,0) at netbsd:panic+0x18
nfs_cache_enter(cab32a28,cab32a34,cab32a40,0,0,cab32a38,cab32a34,cab32a40,0,0) at netbsd:nfs_cache_enter+0xe4
nfs_lookup(cab32a74,c1b397a0,cab32c0c,cab32c0c,cab32a8c,c03841f2,c03d27c8,c1b397a0,cab32ac4,cab32c0c) at netbsd:nfs_lookup+0x6ae
VOP_LOOKUP(c1b397a0,cab32ac4,cab32c0c,2,c1b397a0,cab32ad4,c0bf56d0,cab32bb4,cab32be8,c0be62a0) at netbsd:VOP_LOOKUP+0xa8
lookup_once(cab32b74,cab32b70,4,c040fb80,cab32b0c,c02c8d9b,8,0,cab32be8,cab32b0c) at netbsd:lookup_once+0x19f
namei_tryemulroot(0,c0b1bb40,1,0,c04159cc,cab32be8,cab32c0c,20,0,0) at netbsd:namei_tryemulroot+0x212
namei(cab32be8,cab32c28,0,c0b77568,c0d59400,c0d51dc0,0,c1b397a0,0,1) at netbsd:namei+0x29
do_sys_stat(bb50a3f4,0,cab32c40,b01,0,416d,7,0,2,0) at netbsd:do_sys_stat+0x49
sys___lstat50(c0be62a0,cab32d00,cab32d28,0,c0bfaaf8,1b9,0,bb50f000,cab32d00,c0bf56d0) at netbsd:sys___lstat50+0x2e
syscall(cab32d48,b3,ab,bf7f001f,806001f,bb50a3a0,bb50a3f8,bf7fed38,bb7b15bc,bb50a3a0) at netbsd:syscall+0xaa
cpu0: End traceback...
--
- Brian
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: Brian Marcotte <marcotte@panix.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 21:59:57 +0100
Looks reasonable, I suppose =E2=80=9Cnfs_lookup+0x6ae=E2=80=9D is in =
nfs_lookup:
if (cnp->cn_nameiop !=3D DELETE || !(flags & ISLASTCN)) {
nfs_cache_enter(dvp, newvp, cnp);
}
On the NFS server, what do you get from these commands on the exported =
directory:
ls -ldi /xxxx/.
ls -ldi /xxxx/.zfs/.
ls -ldi /xxxx/.zfs/..
ls -ldi /xxxx/.zfs/shares/.
ls -ldi /xxxx/.zfs/shares/..
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Brian Marcotte <marcotte@panix.com>
To: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Sun, 17 Jan 2016 16:13:02 -0500
> On the NFS server, what do you get from these commands on the exported
> directory:
# ls -ldi /rpool/test/.
4 drwxr-xr-x 2 root root 6 Jan 17 08:31 /rpool/test/.
# ls -ldi /rpool/test/.zfs/.
1 dr-xr-xr-x 4 root root 4 Jan 17 05:31 /rpool/test/.zfs/.
# ls -ldi /rpool/test/.zfs/..
4 drwxr-xr-x 2 root root 6 Jan 17 08:31 /rpool/test/.zfs/..
# ls -ldi /rpool/test/.zfs/shares/.
7 dr-xr-xr-x 2 root root 2 Jan 17 05:31 /rpool/test/.zfs/shares/.
# ls -ldi /rpool/test/.zfs/shares/..
1 dr-xr-xr-x 4 root root 4 Jan 17 05:31 /rpool/test/.zfs/shares/..
The inode numbers were the same on a couple of other filesystems as well.
--
- Brian
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: Brian Marcotte <marcotte@panix.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Mon, 18 Jan 2016 11:06:14 +0100
Bad, ZFS uses inode number 1 for DOTDOT. Found this message on a =
FreeBSD list:
=
https://lists.freebsd.org/pipermail/freebsd-current/2013-February/039486.h=
tml
> Actually I think I have an explanation, just been busy past couple of =
days.
> The problem is precisely with .zfs/shares, which is a strange beast =
that
> currently has no practical use on FreeBSD.
>=20
> .zfs/shares has its own on-disk node. The node has some special =
properties:
> - it is a directory node
> - it is not reachable from any other node
> - its parent ID is set to itself (as for a root node)
> - its ID is stored in a special filesystem property
Here "its parent ID is set to itself=E2=80=9D leads to the problem. =
This should
occur on root only.
This diff should prevent the crash:
--- nfs_vnops.c 12 Aug 2012 12:59:48 -0000 1.293.4.1
+++ nfs_vnops.c 18 Jan 2016 10:05:07 -0000
@@ -966,8 +966,12 @@ dorpc:
* ".." lookup
*/
VOP_UNLOCK(dvp);
error =3D nfs_nget(dvp->v_mount, fhp, fhsize, &np);
+ if (error =3D=3D 0 && dvp =3D=3D NFSTOV(np)) {
+ vput(NFSTOV(np));
+ error =3D EOPNOTSUPP;
+ }
vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY);
if (error) {
m_freem(mrep);
return error;
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Brian Marcotte <marcotte@panix.com>
To: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Mon, 18 Jan 2016 06:29:21 -0500
> error = nfs_nget(dvp->v_mount, fhp, fhsize, &np);
> + if (error == 0 && dvp == NFSTOV(np)) {
> + vput(NFSTOV(np));
> + error = EOPNOTSUPP;
> + }
> vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY);
This isn't working yet. I put a printf in there as well, and it's not
printing my message before the panic. Also, if DIAGNOSTIC is included,
it still stops at "KASSERT(dvp != *vpp);".
It's still entering vn_lock here:
if ((flags & ISDOTDOT) != 0) {
VOP_UNLOCK(dvp);
}
error = vn_lock(newvp, LK_EXCLUSIVE);
if ((flags & ISDOTDOT) != 0) {
--> vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY);
}
if (error != 0) {
/* newvp has been reclaimed. */
vrele(newvp);
Thanks.
--
- Brian
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: Brian Marcotte <marcotte@panix.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Mon, 18 Jan 2016 12:46:51 +0100
> This isn't working yet. I put a printf in there as well, and it's not
> printing my message before the panic. Also, if DIAGNOSTIC is included,
> it still stops at "KASSERT(dvp !=3D *vpp);=E2=80=9D.
This is the second lookup, reading from name cache.
What prints this diff?
--- nfs_vnops.c 12 Aug 2012 12:59:48 -0000 1.293.4.1
+++ nfs_vnops.c 18 Jan 2016 11:45:53 -0000
@@ -946,8 +946,9 @@ dorpc:
* because it should be done while dvp is locked (unlocking
* dvp is different for each case).
*/
=20
+printf("lookup \"%.*s\"\n", cnp->cn_namelen, cnp->cn_nameptr);
if (NFS_CMPFH(np, fhp, fhsize)) {
/*
* as we handle "." lookup locally, this should be
* a broken server.
@@ -960,8 +961,9 @@ dorpc:
nfsm_postop_attr(dvp, attrflag, 0);
} else
#endif
nfsm_loadattr(newvp, (struct vattr *)0, 0);
+printf("dvp %p newvp %p DOT\n", dvp, newvp);
} else if (flags & ISDOTDOT) {
/*
* ".." lookup
*/
@@ -980,8 +982,9 @@ dorpc:
nfsm_postop_attr(dvp, attrflag, 0);
} else
#endif
nfsm_loadattr(newvp, (struct vattr *)0, 0);
+printf("dvp %p newvp %p DOTDOT\n", dvp, newvp);
} else {
/*
* Other lookups.
*/
@@ -997,8 +1000,9 @@ dorpc:
nfsm_postop_attr(dvp, attrflag, 0);
} else
#endif
nfsm_loadattr(newvp, (struct vattr *)0, 0);
+printf("dvp %p newvp %p OTHER\n", dvp, newvp);
}
if (cnp->cn_nameiop !=3D DELETE || !(flags & ISLASTCN)) {
nfs_cache_enter(dvp, newvp, cnp);
}
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Brian Marcotte <marcotte@panix.com>
To: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Mon, 18 Jan 2016 07:07:51 -0500
> What prints this diff?
# cd /net/u
# ls -la
lookup "1"
dvp 0xc17e0dd0 newvp 0xc17e0bc0 OTHER
lookup "2"
dvp 0xc17e0dd0 newvp 0xc17e0b10 OTHER
lookup "dir"
dvp 0xc17e0dd0 newvp 0xc17e0a60 OTHER
lookup "3"
dvp 0xc17e0dd0 newvp 0xc17e09b0 OTHER
lookup "4"
dvp 0xc17e0dd0 newvp 0xc17e0900 OTHER
total 5
drwxr-xr-x 3 root wheel 7 Jan 18 06:19 .
drwxr-xr-x 3 root wheel 512 Jan 17 07:36 ..
-rw-r--r-- 1 root wheel 0 Jan 17 08:31 1
-rw-r--r-- 1 root wheel 0 Jan 17 08:31 2
-rw-r--r-- 1 root wheel 0 Jan 17 08:31 3
-rw-r--r-- 1 root wheel 0 Jan 17 08:31 4
drwxr-xr-x 2 root wheel 2 Jan 18 06:19 dir
# cd dir
# ls -la
lookup ".."
dvp 0xc17e0a60 newvp 0xc17e0dd0 DOTDOT
total 1
drwxr-xr-x 2 root wheel 2 Jan 18 06:19 .
drwxr-xr-x 3 root wheel 7 Jan 18 06:19 ..
# cd ..
# cd .zfs
lookup ".zfs"
dvp 0xc17e0dd0 newvp 0xc17e0850 OTHER
# cd shares
lookup "shares"
dvp 0xc17e0850 newvp 0xc17e07a0 OTHER
# cd ..
lookup ".."
dvp 0xc17e07a0 newvp 0xc17e07a0 DOT
Reader / writer lock error: rw_vector_enter: locking against myself
--
- Brian
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: Brian Marcotte <marcotte@panix.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Mon, 18 Jan 2016 13:19:19 +0100
My bad, sorry. What happens with
--- nfs_vnops.c 12 Aug 2012 12:59:48 -0000 1.293.4.1
+++ nfs_vnops.c 18 Jan 2016 12:18:01 -0000
@@ -951,8 +951,12 @@ dorpc:
/*
* as we handle "." lookup locally, this should be
* a broken server.
*/
+ if (cnp->cn_namelen != 1 || cnp->cn_nameptr[0] != '.') {
+ m_freem(mrep);
+ return EOPNOTSUPP;
+ }
vref(dvp);
newvp = dvp;
#ifndef NFS_V2_ONLY
if (v3) {
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
From: Brian Marcotte <marcotte@panix.com>
To: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: Re: kern/50664: "cd .." over NFS/ZFS can panic kernel
Date: Mon, 18 Jan 2016 07:54:32 -0500
> My bad, sorry. What happens with
That appears to be working. I also put it into NetBSD-7 and it no
longer causes the process to get stuck.
Thanks so much!
--
- Brian
From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50664 CVS commit: src/sys/nfs
Date: Tue, 19 Jan 2016 10:57:00 +0000
Module Name: src
Committed By: hannken
Date: Tue Jan 19 10:57:00 UTC 2016
Modified Files:
src/sys/nfs: nfs_vnops.c
Log Message:
Return an error if NFSPROC_LOOKUP returns the file handle of the current
directory. Treating it as DOT lookup would put garbage into the name
cache and could panic on future lookups.
Seen with ZFS file system exported from OmniOS, an OpenSolaris derivative.
Fixes PR kern/50664 "cd .." over NFS/ZFS can panic kernel
To generate a diff of this commit:
cvs rdiff -u -r1.308 -r1.309 src/sys/nfs/nfs_vnops.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Responsible-Changed-From-To: kern-bug-people->hannken
Responsible-Changed-By: hannken@NetBSD.org
Responsible-Changed-When: Tue, 19 Jan 2016 11:11:54 +0000
Responsible-Changed-Why:
Take.
State-Changed-From-To: open->analyzed
State-Changed-By: hannken@NetBSD.org
State-Changed-When: Tue, 19 Jan 2016 11:11:54 +0000
State-Changed-Why:
Committed a fix.
Needs pullup to -6 and -7.
State-Changed-From-To: analyzed->pending-pullups
State-Changed-By: hannken@NetBSD.org
State-Changed-When: Mon, 25 Jan 2016 15:01:47 +0000
State-Changed-Why:
Pullups requested.
Ticket #1094 for NetBSD-7.
Ticket #1363 for NetBSD-6.
From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50664 CVS commit: [netbsd-7] src/sys/nfs
Date: Sat, 6 Feb 2016 20:52:36 +0000
Module Name: src
Committed By: snj
Date: Sat Feb 6 20:52:36 UTC 2016
Modified Files:
src/sys/nfs [netbsd-7]: nfs_vnops.c
Log Message:
Pull up following revision(s) (requested by hannken in ticket #1094):
sys/nfs/nfs_vnops.c: revision 1.309
Return an error if NFSPROC_LOOKUP returns the file handle of the current
directory. Treating it as DOT lookup would put garbage into the name
cache and could panic on future lookups.
Seen with ZFS file system exported from OmniOS, an OpenSolaris derivative.
Fixes PR kern/50664 "cd .." over NFS/ZFS can panic kernel
To generate a diff of this commit:
cvs rdiff -u -r1.306.2.1 -r1.306.2.2 src/sys/nfs/nfs_vnops.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50664 CVS commit: [netbsd-7-0] src/sys/nfs
Date: Sat, 6 Feb 2016 20:55:12 +0000
Module Name: src
Committed By: snj
Date: Sat Feb 6 20:55:12 UTC 2016
Modified Files:
src/sys/nfs [netbsd-7-0]: nfs_vnops.c
Log Message:
Pull up following revision(s) (requested by hannken in ticket #1094):
sys/nfs/nfs_vnops.c: revision 1.309
Return an error if NFSPROC_LOOKUP returns the file handle of the current
directory. Treating it as DOT lookup would put garbage into the name
cache and could panic on future lookups.
Seen with ZFS file system exported from OmniOS, an OpenSolaris derivative.
Fixes PR kern/50664 "cd .." over NFS/ZFS can panic kernel
To generate a diff of this commit:
cvs rdiff -u -r1.306.2.1 -r1.306.2.1.2.1 src/sys/nfs/nfs_vnops.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50664 CVS commit: [netbsd-6-0] src/sys/nfs
Date: Thu, 14 Jul 2016 06:52:57 +0000
Module Name: src
Committed By: snj
Date: Thu Jul 14 06:52:57 UTC 2016
Modified Files:
src/sys/nfs [netbsd-6-0]: nfs_vnops.c
Log Message:
Pull up following revision(s) (requested by hannken in ticket #1363):
sys/nfs/nfs_vnops.c: revision 1.309
Return an error if NFSPROC_LOOKUP returns the file handle of the current
directory. Treating it as DOT lookup would put garbage into the name
cache and could panic on future lookups.
Seen with ZFS file system exported from OmniOS, an OpenSolaris derivative.
Fixes PR kern/50664 "cd .." over NFS/ZFS can panic kernel
To generate a diff of this commit:
cvs rdiff -u -r1.293.4.1 -r1.293.4.1.4.1 src/sys/nfs/nfs_vnops.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50664 CVS commit: [netbsd-6-1] src/sys/nfs
Date: Thu, 14 Jul 2016 06:55:08 +0000
Module Name: src
Committed By: snj
Date: Thu Jul 14 06:55:08 UTC 2016
Modified Files:
src/sys/nfs [netbsd-6-1]: nfs_vnops.c
Log Message:
Pull up following revision(s) (requested by hannken in ticket #1363):
sys/nfs/nfs_vnops.c: revision 1.309
Return an error if NFSPROC_LOOKUP returns the file handle of the current
directory. Treating it as DOT lookup would put garbage into the name
cache and could panic on future lookups.
Seen with ZFS file system exported from OmniOS, an OpenSolaris derivative.
Fixes PR kern/50664 "cd .." over NFS/ZFS can panic kernel
To generate a diff of this commit:
cvs rdiff -u -r1.293.4.1 -r1.293.4.1.6.1 src/sys/nfs/nfs_vnops.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50664 CVS commit: [netbsd-6] src/sys/nfs
Date: Thu, 14 Jul 2016 06:57:12 +0000
Module Name: src
Committed By: snj
Date: Thu Jul 14 06:57:12 UTC 2016
Modified Files:
src/sys/nfs [netbsd-6]: nfs_vnops.c
Log Message:
Pull up following revision(s) (requested by hannken in ticket #1363):
sys/nfs/nfs_vnops.c: revision 1.309
Return an error if NFSPROC_LOOKUP returns the file handle of the current
directory. Treating it as DOT lookup would put garbage into the name
cache and could panic on future lookups.
Seen with ZFS file system exported from OmniOS, an OpenSolaris derivative.
Fixes PR kern/50664 "cd .." over NFS/ZFS can panic kernel
To generate a diff of this commit:
cvs rdiff -u -r1.293.4.1 -r1.293.4.2 src/sys/nfs/nfs_vnops.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: snj@NetBSD.org
State-Changed-When: Thu, 14 Jul 2016 07:08:47 +0000
State-Changed-Why:
Pullups complete.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home