NetBSD Problem Report #54541
From www@netbsd.org Tue Sep 10 13:30:46 2019
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 "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 265407A1E3
for <gnats-bugs@gnats.NetBSD.org>; Tue, 10 Sep 2019 13:30:46 +0000 (UTC)
Message-Id: <20190910133045.0EEB07A1E9@mollari.NetBSD.org>
Date: Tue, 10 Sep 2019 13:30:45 +0000 (UTC)
From: joernc@posteo.de
Reply-To: joernc@posteo.de
To: gnats-bugs@NetBSD.org
Subject: kernel panic using "zfs diff"
X-Send-Pr-Version: www-1.0
>Number: 54541
>Category: kern
>Synopsis: kernel panic using "zfs diff"
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Sep 10 13:35:00 +0000 2019
>Closed-Date: Tue Nov 05 11:28:44 +0000 2019
>Last-Modified: Tue Nov 05 11:28:44 +0000 2019
>Originator: Joern Clausen
>Release: NetBSD 9.0/amd64 BETA
>Organization:
>Environment:
NetBSD localhost 9.0_BETA NetBSD 9.0_BETA (GENERIC) #0: Sat Sep 7 18:06:30 UTC 2019 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
Environment: VirtualBox VM with 2 vCPUs and 4 GB RAM
$ zpool status
pool: data-cc
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
data-cc ONLINE 0 0 0
sd0 ONLINE 0 0 0
sd1 ONLINE 0 0 0
errors: No known data errors
pool: data-mr
state: ONLINE
scan: resilvered 77K in 0h0m with 0 errors on Tue Sep 10 14:20:18 2019
config:
NAME STATE READ WRITE CKSUM
data-mr ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sd2 ONLINE 0 0 0
sd3 ONLINE 0 0 0
errors: No known data errors
$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
data-cc 560M 30.2G 23K /data-cc
data-cc/pkgsrc 559M 30.2G 559M /usr/pkgsrc
data-mr 192M 15.2G 23K /data-mr
data-mr/pkg 191M 15.2G 191M /usr/pkg
$ zfs list -t snapshot
zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
data-mr/pkg@pre_wireshark 331K - 77.8M -
(BTW: IMHO it would be nice if "zfs list" would already show snapshots.)
The command
$ zfs diff data-mr/pkg@pre_wireshark
results in a kernel panic. After the next boot, this message is in /var/log/messages:
Sep 10 15:14:19 localhost savecore: reboot after panic: [ 3294.7831635] panic: kernel diagnostic assertion "fdm != NULL" failed: file "/usr/src/sys/kern/vfs_trans.c", line 166 mount 0x0 invalid
Sep 10 15:14:19 localhost savecore: system went down at Tue Sep 10 15:12:21 2019
and unfurtunately on my machine
Sep 10 15:14:19 localhost savecore: no dump, not enough free space in /var/crash
This error is repeatable, i.e. after a reboot, "zfs diff" will crash the machine again.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Tue, 10 Sep 2019 16:22:32 +0100
> data-cc/pkgsrc 559M 30.2G 559M /usr/pkgsrc
...
I tried to reproduce this, but got stuck earlier:
zfs create bpi/pkgsrc
cd /bpi/pkgsrc
ftp http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc.tar.bz2
tar xzf pkgsrc.tar.bz2
cd pkgsrc; mv * .. ; cd ..; rmdir pkgsrc
zfs snapshot bpi/pkgsrc@orig
cvs -z3 update -Pd
and the update doesn't finish
cvs update: Updating x11/zenity/patches
PID LID USERNAME PRI STATE TIME WCPU CPU NAME COMMAND
880 1 root 85 zfscv/3 0:55 0.00% 0.00% - cvs
611 1 prlw 85 select/0 0:14 0.00% 0.00% - sshd
0 137 root 124 syncer/0 0:04 0.00% 0.00% ioflush [system]
0 223 root 96 zfscv/3 0:03 0.00% 0.00% zfs [system]
0 130 root 221 raidio/0 0:02 0.00% 0.00% raidio0 [system]
0 362 root 127 zfscv/7 0:01 0.00% 0.00% zio_write [system]
0 364 root 127 zfscv/2 0:01 0.00% 0.00% zio_write [system]
0 363 root 127 zfscv/0 0:01 0.00% 0.00% zio_write [system]
0 371 root 127 zfscv/2 0:01 0.00% 0.00% zio_write [system]
0 370 root 127 zfscv/3 0:01 0.00% 0.00% zio_write [system]
0 374 root 127 zfscv/1 0:01 0.00% 0.00% zio_write [system]
0 372 root 127 zfscv/0 0:01 0.00% 0.00% zio_write [system]
0 373 root 127 zfscv/7 0:01 0.00% 0.00% zio_write [system]
0 376 root 126 zfscv/7 0:01 0.00% 0.00% zio_write [system]
0 375 root 126 zfscv/6 0:01 0.00% 0.00% zio_write [system]
0 369 root 126 zfscv/3 0:01 0.00% 0.00% zio_write [system]
0 368 root 126 zfscv/4 0:01 0.00% 0.00% zio_write [system]
0 367 root 126 zfscv/7 0:01 0.00% 0.00% zio_write [system]
0 382 root 126 zfscv/2 0:01 0.00% 0.00% zio_write [system]
337 1 root 85 select/2 0:01 0.00% 0.00% - ssh
0 173 root 43 atafin/1 0:01 0.00% 0.00% vdevsync [system]
0 170 root 43 atafin/3 0:01 0.00% 0.00% vdevsync [system]
From: =?utf-8?Q?J=C3=B6rn_Clausen?= <joernc@posteo.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Tue, 10 Sep 2019 17:42:38 +0200
--Apple-Mail=_3ED1EA02-6CB3-439B-AC09-89A73A4645A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Am 10.09.2019 um 17:25 schrieb Patrick Welche <prlw1@cam.ac.uk>:
> I tried to reproduce this, but got stuck earlier:
How much memory do you have? I started with 2 GB RAM, and the machine =
froze early during a bonnie-run. The requirement for 4 GB minimum should =
probably be enforced in some way when using ZFS. Or ZFS should fail more =
gracefully in low-memory situations.
--
Joern Clausen
https://www.oe-files.de/photography/
--Apple-Mail=_3ED1EA02-6CB3-439B-AC09-89A73A4645A3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEzBAEBCgAdFiEEzVooW1PV8KYCsXHJn81JK3TC7BIFAl13xG4ACgkQn81JK3TC
7BJz5wgAg47G7SOg37CzgM4pXcdIzIgP2QJGvQDr3tt3iQGfJEdwFrO4ex4yNJKg
/DXA6/QQxTVlCCdIUtXIRBllvHr704B0P75qWzxwcs9sNjvnLCiIeZTFXfd9j/pH
GN9ShWEwwPKK8rZvw6B/InUtqv13NNN2OpXT2Uio5RpJcegpSMSDbjepRsCANQhh
ffrYPNbl36L6liWoJYBSkQJubS7dM3qzhKSqSs7rc0HreCe0kxjewGLeKsDZ1qZq
du++wwLjvHY+6mwssHQnS1G8DsUzqMRSJs+bOP1d2DRtfh4sbVkRRi0imkEswapN
lnoB0aNJfRxwG2/w32QnclNJgq/71Q==
=Nq5M
-----END PGP SIGNATURE-----
--Apple-Mail=_3ED1EA02-6CB3-439B-AC09-89A73A4645A3--
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Tue, 10 Sep 2019 16:51:12 +0100
On Tue, Sep 10, 2019 at 03:45:01PM +0000, J?rn Clausen wrote:
> How much memory do you have? I started with 2 GB RAM, and the machine =
> froze early during a bonnie-run. The requirement for 4 GB minimum should =
> probably be enforced in some way when using ZFS. Or ZFS should fail more =
> gracefully in low-memory situations.
16 GB - this is just a GENERIC kernel. I'll trying adding DEBUG & friends...
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Wed, 11 Sep 2019 10:51:18 +0100
On Tue, Sep 10, 2019 at 04:30:01PM +0000, Patrick Welche wrote:
> 16 GB - this is just a GENERIC kernel. I'll trying adding DEBUG & friends...
I simply tried again without changing the kernel, and let it run. It
eventually completed. (straw clutching: could kern/53124 also apply
to zfs - 4 cores 8 threads)
Back to the PR:
# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
bpi/pkgsrc@orig 47.4M - 403M -
# zfs diff bpi/pkgsrc@orig
caused a freeze with nothing appearing on the console. Of course
this box doesn't even have a serial header on its motherboard.
From: =?UTF-8?Q?J=C3=B6rn_Clausen?= <joernc@posteo.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Thu, 12 Sep 2019 08:55:00 +0200
Just for the record: Access to .zfs/snapshot/... did work, and getting
rid of the snapshot with "zfs destroy" also worked without problems.
--
Joern Clausen
http://www.oe-files.de/photography/
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Thu, 12 Sep 2019 14:35:32 +0100
On Wed, Sep 11, 2019 at 09:55:01AM +0000, Patrick Welche wrote:
> caused a freeze with nothing appearing on the console. Of course
> this box doesn't even have a serial header on its motherboard.
Finally got there - I see your panic:
panic: kernel diagnostic assertion "fdm != NULL" failed: file "../../../../kern/vfs_trans.c", line 166 mount 0x0 invalid
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x160
stge_eeprom_wait.isra.4() at netbsd:stge_eeprom_wait.isra.4
fstrans_alloc_lwp_info() at netbsd:fstrans_alloc_lwp_info+0x283
fstrans_start() at netbsd:fstrans_start+0x3f
VOP_LOCK() at netbsd:VOP_LOCK+0x4c
vn_lock() at netbsd:vn_lock+0xa1
vn_rdwr() at netbsd:vn_rdwr+0x136
write_record.part.1() at zfs:write_record.part.1+0x54
diff_cb() at zfs:diff_cb+0x236
traverse_visitbp() at zfs:traverse_visitbp+0x1b6
traverse_visitbp() at zfs:traverse_visitbp+0x52b
traverse_visitbp() at zfs:traverse_visitbp+0x52b
traverse_visitbp() at zfs:traverse_visitbp+0x52b
traverse_visitbp() at zfs:traverse_visitbp+0x52b
traverse_visitbp() at zfs:traverse_visitbp+0x52b
traverse_dnode() at zfs:traverse_dnode+0xda
traverse_visitbp() at zfs:traverse_visitbp+0x8ab
traverse_impl() at zfs:traverse_impl+0x16c
traverse_dataset_resume() at zfs:traverse_dataset_resume+0x44
dmu_diff() at zfs:dmu_diff+0x14c
zfs_ioc_diff() at zfs:zfs_ioc_diff+0x42
zfsdev_ioctl() at zfs:zfsdev_ioctl+0x265
nb_zfsdev_ioctl() at zfs:nb_zfsdev_ioctl+0x38
VOP_IOCTL() at netbsd:VOP_IOCTL+0x54
vn_ioctl() at netbsd:vn_ioctl+0xa5
sys_ioctl() at netbsd:sys_ioctl+0x5ab
syscall() at netbsd:syscall+0x196
--- syscall (number 54) ---
and found a crash dump.
(gdb) frame 4
#4 fstrans_alloc_lwp_info (mp=mp@entry=0x0)
at ../../../../kern/vfs_trans.c:383
383 fstrans_debug_validate_mount(mp);
(gdb) list
378 /*
379 * Attach the entry to the mount if its mnt_transinfo is valid380 */
381
382 mutex_enter(&fstrans_mount_lock);
383 fstrans_debug_validate_mount(mp);
384 fmi = mp->mnt_transinfo;
385 KASSERT(fmi != NULL);
386 fli->fli_mount = mp;
387 fli->fli_mountinfo = fmi;
(gdb) print *mp
Cannot access memory at address 0x0
The back trace is what was in dmesg. I can't see zfs_anything() using gdb.
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Thu, 12 Sep 2019 16:17:00 +0100
export RUMP_SERVER=unix://zsock
rump.halt 2> /dev/null
rump_server -lrumpvfs -lrumpdev_disk -lrumpkern_solaris -lrumpfs_zfs -lrumpdev -lrumpdev_rnd -d key=/dk,hostpath=zfs.img,size=100m ${RUMP_SERVER}
export LD_PRELOAD=/usr/lib/librumphijack.so
export RUMPHIJACK=blanket=/dev/zfs:/dk:/storage,sysctl=yes,modctl=yes
zpool create storage /dk
zpool list
zfs list
echo hello | rump.dd of=/storage/hello
ls -l /storage
zfs list
zfs snapshot storage@hello
echo bar | rump.dd of=/storage/bar
ls -l /storage
zfs list
zfs list -t snapshot
zfs diff storage@hello
seems to contain a "Cannot create just-in-time snapshot of 'storage'" clue...
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Wed, 9 Oct 2019 15:27:18 +0100
Today's ptrace patch makes gdb work much better...
make_temp_snapshot calls ioctl(ZFS_IOC_TMP_SNAPSHOT)
zfs_ioc_tmp_snapshot calls zfs_onexit_fd_hold
zfs_onexit_fd_hold calls fd_getfile(133) which returns NULL. why?!
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Wed, 9 Oct 2019 16:12:50 +0100
On Wed, Oct 09, 2019 at 02:30:02PM +0000, Patrick Welche wrote:
> zfs_onexit_fd_hold calls fd_getfile(133) which returns NULL. why?!
(gdb) print fdp->fd_dt->dt_nfiles
$6 = 20
and 133 > 20
better trace:
(gdb) bt
#0 fd_getfile (fd=133)
at /usr/src/lib/librump/../../sys/rump/../kern/kern_descrip.c:365
#1 0x00007f7ff4e6ab8d in zfs_onexit_fd_hold (fd=<optimized out>,
minorp=0x7f7fe2b3fbbc)
at /usr/src/sys/../external/cddl/osnet/dist/uts/common/fs/zfs/zfs_onexit.c:145
#2 0x00007f7ff4e6e2b9 in zfs_ioc_tmp_snapshot (zc=0x7f7ff481b000)
at /usr/src/sys/../external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c:5252
#3 0x00007f7ff4e765d2 in zfsdev_ioctl (dev=dev@entry=48640,
zcmd=zcmd@entry=3222821432, iarg=iarg@entry=140187241020992,
flag=flag@entry=3, cr=<optimized out>, rvalp=rvalp@entry=0x7f7fe2b3fcac)
at /usr/src/sys/../external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c:6592
#4 0x00007f7ff4e769e7 in nb_zfsdev_ioctl (dev=48640, cmd=3222821432,
argp=0x7f7fe2b3fe40, flag=3, l=<optimized out>)
at /usr/src/sys/../external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c:7058
#5 0x00007f7ff745f807 in VOP_IOCTL (vp=0x7f7ff72c16f0,
command=<optimized out>, data=<optimized out>, fflag=<optimized out>,
cred=<optimized out>)
at /usr/src/lib/librump/../../sys/rump/../kern/vnode_if.c:610
#6 0x00007f7ff7030285 in vn_ioctl (fp=0x7f7ff6bcc440, com=3222821432,
data=0x7f7fe2b3fe40)
at /usr/src/lib/librumpvfs/../../sys/rump/../kern/vfs_vnops.c:775
#7 0x00007f7ff744e593 in sys_ioctl (l=<optimized out>, uap=0x7f7ff6b3bf80,
retval=<optimized out>)
at /usr/src/lib/librump/../../sys/rump/../kern/sys_generic.c:671
#8 0x00007f7ff7801319 in sy_call (rval=0x7f7fe2b3ff10, uap=0x7f7ff6b3bf80,
l=0x7f7ff6a361c0, sy=0x7f7ff76f98d0 <rumpns_sysent+1296>)
at /usr/src/sys/rump/kern/lib/libsysproxy/../../../../sys/syscallvar.h:65
#9 sy_invoke (code=54, rval=0x7f7fe2b3ff10, uap=0x7f7ff6b3bf80,
l=0x7f7ff6a361c0, sy=0x7f7ff76f98d0 <rumpns_sysent+1296>)
at /usr/src/sys/rump/kern/lib/libsysproxy/../../../../sys/syscallvar.h:94
#10 hyp_syscall (num=54, arg=0x7f7ff6b3bf80, retval=0x7f7fe2b3ff90)
at /usr/src/sys/rump/kern/lib/libsysproxy/sysproxy.c:74
#11 0x00007f7ff6c06bd0 in rumpsyscall (regrv=0x7f7fe2b3ff80,
data=0x7f7ff6b3bf80, sysnum=54)
at /usr/src/lib/librumpuser/rumpuser_sp.c:267
#12 serv_handlesyscall (rhdr=0x7f7ff4806b48, rhdr=0x7f7ff4806b48,
data=0x7f7ff6b3bf80 "\003", spc=0x7f7ff6e0b7e8)
at /usr/src/lib/librumpuser/rumpuser_sp.c:690
#13 serv_workbouncer (arg=<optimized out>)
at /usr/src/lib/librumpuser/rumpuser_sp.c:773
#14 0x00007f7ff680c1e8 in pthread__create_tramp (cookie=0x7f7ff6b62c00)
at /usr/src/lib/libpthread/pthread.c:593
#15 0x00007f7ff60901c0 in ?? () from /usr/lib/libc.so.12
#16 0x0000000000000000 in ?? ()
From: Patrick Welche <prlw1@cam.ac.uk>
To: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, joernc@posteo.de
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Wed, 9 Oct 2019 16:52:16 +0100
src/external/cddl/osnet/dist/lib/libzfs/common/libzfs_diff.c:
739 static int
740 setup_differ_info(zfs_handle_t *zhp, const char *fromsnap,
741 const char *tosnap, differ_info_t *di)
742 {
743 di->zhp = zhp;
744
745 di->cleanupfd = open(ZFS_DEV, O_RDWR|O_EXCL);
746 VERIFY(di->cleanupfd >= 0);
747
748 if (get_snapshot_names(di, fromsnap, tosnap) != 0)
749 return (-1);
750
751 if (get_mountpoints(di) != 0)
752 return (-1);
753
754 if (find_shares_object(di) != 0)
755 return (-1);
756
757 return (0);
758 }
so cleanupfd=133 should be OK?
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Wed, 9 Oct 2019 13:03:29 -0400
On Oct 9, 3:55pm, prlw1@cam.ac.uk (Patrick Welche) wrote:
-- Subject: Re: kern/54541: kernel panic using "zfs diff"
| The following reply was made to PR kern/54541; it has been noted by GNATS.
|
| From: Patrick Welche <prlw1@cam.ac.uk>
| To: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
| netbsd-bugs@netbsd.org, joernc@posteo.de
| Cc:
| Subject: Re: kern/54541: kernel panic using "zfs diff"
| Date: Wed, 9 Oct 2019 16:52:16 +0100
|
| src/external/cddl/osnet/dist/lib/libzfs/common/libzfs_diff.c:
| 739 static int
| 740 setup_differ_info(zfs_handle_t *zhp, const char *fromsnap,
| 741 const char *tosnap, differ_info_t *di)
| 742 {
| 743 di->zhp = zhp;
| 744
| 745 di->cleanupfd = open(ZFS_DEV, O_RDWR|O_EXCL);
| 746 VERIFY(di->cleanupfd >= 0);
| 747
| 748 if (get_snapshot_names(di, fromsnap, tosnap) != 0)
| 749 return (-1);
| 750
| 751 if (get_mountpoints(di) != 0)
| 752 return (-1);
| 753
| 754 if (find_shares_object(di) != 0)
| 755 return (-1);
| 756
| 757 return (0);
| 758 }
|
| so cleanupfd=133 should be OK?
https://nxr.netbsd.org/xref/src/lib/librumphijack/hijack.c#433
Something seems to not understand that this is a hijacked fd which it seems
to be: 133 (128 + 5)...
christos
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Fri, 11 Oct 2019 17:01:34 +0100
On Wed, Oct 09, 2019 at 05:05:01PM +0000, Christos Zoulas wrote:
> Something seems to not understand that this is a hijacked fd which it seems
> to be: 133 (128 + 5)...
/dev/zfs is hijacked:
export RUMPHIJACK=blanket=/dev/zfs:/dk:/storage,sysctl=yes,modctl=yes
rumpns_fd_getfile receives the 133 rather than 5 so complains.
So I seem to be seeing a rump issue rather than a zfs issue?
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, joernc@posteo.de
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Fri, 11 Oct 2019 14:44:16 -0400
On Oct 11, 4:05pm, prlw1@cam.ac.uk (Patrick Welche) wrote:
-- Subject: Re: kern/54541: kernel panic using "zfs diff"
| The following reply was made to PR kern/54541; it has been noted by GNATS.
|
| From: Patrick Welche <prlw1@cam.ac.uk>
| To: gnats-bugs@netbsd.org
| Cc:
| Subject: Re: kern/54541: kernel panic using "zfs diff"
| Date: Fri, 11 Oct 2019 17:01:34 +0100
|
| On Wed, Oct 09, 2019 at 05:05:01PM +0000, Christos Zoulas wrote:
| > Something seems to not understand that this is a hijacked fd which it seems
| > to be: 133 (128 + 5)...
|
| /dev/zfs is hijacked:
| export RUMPHIJACK=blanket=/dev/zfs:/dk:/storage,sysctl=yes,modctl=yes
|
| rumpns_fd_getfile receives the 133 rather than 5 so complains.
| So I seem to be seeing a rump issue rather than a zfs issue?
Well, from the stacktrace it seems that it does not get hijacked for some
reason. Why don't you try to break with gdb in the ioctl call?
christos
From: Brad Spencer <brad@anduin.eldar.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
joernc@posteo.de
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Fri, 11 Oct 2019 19:47:33 -0400
Patrick Welche <prlw1@cam.ac.uk> writes:
> The following reply was made to PR kern/54541; it has been noted by GNATS.
>
> From: Patrick Welche <prlw1@cam.ac.uk>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/54541: kernel panic using "zfs diff"
> Date: Fri, 11 Oct 2019 17:01:34 +0100
>
> On Wed, Oct 09, 2019 at 05:05:01PM +0000, Christos Zoulas wrote:
> > Something seems to not understand that this is a hijacked fd which it seems
> > to be: 133 (128 + 5)...
>
> /dev/zfs is hijacked:
> export RUMPHIJACK=blanket=/dev/zfs:/dk:/storage,sysctl=yes,modctl=yes
>
> rumpns_fd_getfile receives the 133 rather than 5 so complains.
> So I seem to be seeing a rump issue rather than a zfs issue?
>
I would say that there is a pretty good chance that rump does not quite
handle ZFS correctly. I won't speculate as to why.
Back to the original kernel dump... This is pretty simple for me to
reproduce this as well... this is a snip I get:
[ 472375.2036056] panic: kernel diagnostic assertion "fdm != NULL" failed: file "/usr/src/sys/kern/vfs_trans.c", line 166 mount 0x0 invalid
.
.
.
[ 472375.2036056] vn_rdwr() at netbsd:vn_rdwr+0x136
[ 472375.2036056] write_record.part.1() at zfs:write_record.part.1+0x54
[ 472375.2036056] diff_cb() at zfs:diff_cb+0x236
[ 472375.2036056] traverse_visitbp() at zfs:traverse_visitbp+0x1b6
[ 472375.2036056] traverse_visitbp() at zfs:traverse_visitbp+0x52b
[ 472375.2036056] traverse_visitbp() at zfs:traverse_visitbp+0x52b
[ 472375.2036056] traverse_visitbp() at zfs:traverse_visitbp+0x52b
[ 472375.2036056] traverse_visitbp() at zfs:traverse_visitbp+0x52b
[ 472375.2036056] traverse_visitbp() at zfs:traverse_visitbp+0x52b
[ 472375.2036056] traverse_dnode() at zfs:traverse_dnode+0xda
[ 472375.2036056] traverse_visitbp() at zfs:traverse_visitbp+0x8ab
[ 472375.2036056] traverse_impl() at zfs:traverse_impl+0x16c
[ 472375.2036056] traverse_dataset_resume() at zfs:traverse_dataset_resume+0x44
[ 472375.2036056] dmu_diff() at zfs:dmu_diff+0x14c
The write_record call is in
src/external/cddl/osnet/dist/uts/common/fs/zfs/dmu_diff.c and it is
pretty small. It might be interesting to know what the arguments to the
single vn_rdwr call are.
I won't have time right now to find this out for myself, however....
Recursion is involved in all of this, that is what the traverse_visitbp
stuff is all about that is mentioned in the panic messages, and I wonder
if there is a missing or mishandled terminator condition. The panic
itself, in my case, is tripped by a DIAGNOSTIC assert check in a VOP
function. It is a little confusing, but diff_cb is a call back (of some
sort) that appears to be set up by a call to traverse_dataset which gets
translated in the panic as traverse_dataset_resume (I think).
I can only run this on a DOMU, so no kernel dumps, but I suspect that if
one could get a clean kernel dump somewhere else it would all become
clear what is going on.
--
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Sat, 12 Oct 2019 10:02:28 +0200
--Apple-Mail=_972375B2-1082-40B3-A97E-2DCE98FFC5F4
Content-Type: multipart/mixed;
boundary="Apple-Mail=_58C83D04-59EA-49F3-9B5C-324811C87CF1"
--Apple-Mail=_58C83D04-59EA-49F3-9B5C-324811C87CF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> On 12. Oct 2019, at 01:50, Brad Spencer <brad@anduin.eldar.org> wrote:
<snip>
>=20
> [ 472375.2036056] panic: kernel diagnostic assertion "fdm !=3D NULL" =
failed: file "/usr/src/sys/kern/vfs_trans.c", line 166 mount 0x0 invalid
Sorry for being late, looks like vn_rdwr() gets called
with garbage instead of a vnode.
The attached diff could help to track it down.
Do you have a recipe to trigger this panic?
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig
--Apple-Mail=_58C83D04-59EA-49F3-9B5C-324811C87CF1
Content-Disposition: attachment;
filename=zfs_ioctl.c.diff
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="zfs_ioctl.c.diff"
Content-Transfer-Encoding: 7bit
--- zfs_ioctl.c 22 May 2019 08:46:27 -0000 1.20
+++ zfs_ioctl.c 12 Oct 2019 07:58:07 -0000
@@ -5297,4 +5297,6 @@ zfs_ioc_diff(zfs_cmd_t *zc)
off = fp->f_offset;
+ KASSERTMSG(fp->f_type == DTYPE_VNODE, "type=%u", fp->f_type);
+
#ifdef __FreeBSD__
error = dmu_diff(zc->zc_name, zc->zc_value, fp, &off);
--Apple-Mail=_58C83D04-59EA-49F3-9B5C-324811C87CF1--
--Apple-Mail=_972375B2-1082-40B3-A97E-2DCE98FFC5F4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE2BL3ha7Xao4WUZVYKoaVJdNr+uEFAl2hiJQACgkQKoaVJdNr
+uGAUggAi3UdG/ey3l87h76tbtpzihGsqJroA1KCsi+fWVIwddjcHaPlsx+vHX0Y
ImMNYEg260X/JaQCvcY7v19zU3Cxu9NQE2VGVcYStx7RS0agiVmC+lDg/GE8ZOzH
K1l+sEhOltFKtbI76l4NsXO9+k8ow4sVcPnMEolZ79HfvoxphNSRt6cpSS2JjEK5
euesZuVuAKgD+WsnAWmiCdnLGQh8Nm/ZxuKk9zIJJs06a46JSKkE+k8yjxpP/t0a
pzjv4VplIr2TeHEijITdM7DHC9IU1tDOHFMOyWV2SsvXJLx4YfHljpb3HPUcFO35
vTdXqrBi0gbZBMLEvafgHi2MC/Oq2A==
=vRS0
-----END PGP SIGNATURE-----
--Apple-Mail=_972375B2-1082-40B3-A97E-2DCE98FFC5F4--
From: Brad Spencer <brad@anduin.eldar.org>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
joernc@posteo.de
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Sat, 12 Oct 2019 07:33:14 -0400
"J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de> writes:
> The following reply was made to PR kern/54541; it has been noted by GNATS.
>
> From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/54541: kernel panic using "zfs diff"
> Date: Sat, 12 Oct 2019 10:02:28 +0200
>
> --Apple-Mail=_972375B2-1082-40B3-A97E-2DCE98FFC5F4
> Content-Type: multipart/mixed;
> boundary="Apple-Mail=_58C83D04-59EA-49F3-9B5C-324811C87CF1"
>
>
> --Apple-Mail=_58C83D04-59EA-49F3-9B5C-324811C87CF1
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
> charset=us-ascii
>
> > On 12. Oct 2019, at 01:50, Brad Spencer <brad@anduin.eldar.org> wrote:
> <snip>
> >=20
> > [ 472375.2036056] panic: kernel diagnostic assertion "fdm !=3D NULL" =
> failed: file "/usr/src/sys/kern/vfs_trans.c", line 166 mount 0x0 invalid
>
> Sorry for being late, looks like vn_rdwr() gets called
> with garbage instead of a vnode.
>
> The attached diff could help to track it down.
>
> Do you have a recipe to trigger this panic?
>
> --
> J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig
For me personally, it is something like this, although I don't know how
much of this matters:
sysctl -w ddb.onpanic=1
zpool create tank xbd4d <- 1GB presented to a DOMU
zfs create tank/ds1
zfs set quota=100m tank/ds1
(fill tank/ds1 up to about 80% or so with anything, I used multiple files, but I doubt that matters)
zfs snapshot tank/ds1@sn1
(change tank/ds1. Add or delete something, I think any change will work)
You will end up with something like this:
test3# zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
rstuff 264M 1.55G 23K /rstuff
rstuff/var 261M 139M 261M legacy
tank 80.8M 1.73G 23K /tank
tank/ds1 80.2M 19.8M 80.2M /tank/ds1
tank/ds1@sn1 18K - 80.2M -
zfs diff tank/ds1@sn1
panic here
I applied the included patch to a test build which is building now, but
I can't retest this for a bit. The test DOMU that triggers this has 1GB
of memory given to it and is running a pretty recent build.
--
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Sat, 12 Oct 2019 13:57:07 +0200
--Apple-Mail=_FC1C4FEB-E02A-47BF-8CBB-D3C164AF2FC6
Content-Type: multipart/mixed;
boundary="Apple-Mail=_263A2ADB-9D83-4DF5-A153-C9D927E63EA4"
--Apple-Mail=_263A2ADB-9D83-4DF5-A153-C9D927E63EA4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
Ok, dmu_diff() gets called with a file of type "pipe" and
treating it as "vnode" fails badly.
Please try the attached diff.
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig
--Apple-Mail=_263A2ADB-9D83-4DF5-A153-C9D927E63EA4
Content-Disposition: attachment;
filename=54541.diff
Content-Type: application/octet-stream;
x-unix-mode=0644;
name="54541.diff"
Content-Transfer-Encoding: 7bit
dmu_diff
Change dmu_diff() back to use a "file" instead of a "vnode".
Command "zfs diff" calls it with a pipe, not a plain file.
Should fix PR kern/54541: kernel panic using "zfs diff"
diff -r 78bb594e351e -r f95f69bb5abe external/cddl/osnet/dist/uts/common/fs/zfs/dmu_diff.c
--- external/cddl/osnet/dist/uts/common/fs/zfs/dmu_diff.c
+++ external/cddl/osnet/dist/uts/common/fs/zfs/dmu_diff.c
@@ -43,16 +43,13 @@
struct diffarg {
#ifdef __FreeBSD__
kthread_t *da_td;
+#endif
struct file *da_fp; /* file to which we are reporting */
-#else
- struct vnode *da_vp; /* file to which we are reporting */
-#endif
offset_t *da_offp;
int da_err; /* error that stopped diff search */
dmu_diff_record_t da_ddr;
};
-#ifdef __FreeBSD__
static int
write_bytes(struct diffarg *da)
{
@@ -66,18 +63,30 @@ write_bytes(struct diffarg *da)
auio.uio_resid = aiov.iov_len;
auio.uio_rw = UIO_WRITE;
auio.uio_offset = (off_t)-1;
+#ifdef __FreeBSD__
auio.uio_segflg = UIO_SYSSPACE;
auio.uio_td = da->da_td;
+#else
+ auio.uio_vmspace = vmspace_kernel();
+#endif /* __FreeBSD__ */
#ifdef _KERNEL
+#ifdef __FreeBSD__
if (da->da_fp->f_type == DTYPE_VNODE)
bwillwrite();
return (fo_write(da->da_fp, &auio, da->da_td->td_ucred, 0, da->da_td));
#else
+ int flags = 0;
+
+ if (da->da_fp->f_type == DTYPE_VNODE)
+ flags |= FOF_UPDATE_OFFSET;
+ return (*da->da_fp->f_ops->fo_write)(da->da_fp, &da->da_fp->f_offset,
+ &auio, da->da_fp->f_cred, flags);
+#endif /* __FreeBSD__ */
+#else
fprintf(stderr, "%s: returning EOPNOTSUPP\n", __func__);
return (EOPNOTSUPP);
#endif
}
-#endif /* __FreeBSD__ */
static int
write_record(struct diffarg *da)
@@ -89,13 +98,7 @@ write_record(struct diffarg *da)
return (0);
}
-#ifdef __FreeBSD__
da->da_err = write_bytes(da);
-#else
- da->da_err = vn_rdwr(UIO_WRITE, da->da_vp, (caddr_t)&da->da_ddr,
- sizeof (da->da_ddr), 0, UIO_SYSSPACE, FAPPEND,
- RLIM64_INFINITY, CRED(), &resid);
-#endif
*da->da_offp += sizeof (da->da_ddr);
return (da->da_err);
}
@@ -193,11 +196,7 @@ diff_cb(spa_t *spa, zilog_t *zilog, cons
int
dmu_diff(const char *tosnap_name, const char *fromsnap_name,
-#ifdef __FreeBSD__
struct file *fp, offset_t *offp)
-#else
- struct vnode *vp, offset_t *offp)
-#endif
{
struct diffarg da;
dsl_dataset_t *fromsnap;
@@ -242,10 +241,8 @@ dmu_diff(const char *tosnap_name, const
#ifdef __FreeBSD__
da.da_td = curthread;
+#endif
da.da_fp = fp;
-#else
- da.da_vp = vp;
-#endif
da.da_offp = offp;
da.da_ddr.ddr_type = DDR_NONE;
da.da_ddr.ddr_first = da.da_ddr.ddr_last = 0;
diff -r 78bb594e351e -r f95f69bb5abe external/cddl/osnet/dist/uts/common/fs/zfs/sys/dmu.h
--- external/cddl/osnet/dist/uts/common/fs/zfs/sys/dmu.h
+++ external/cddl/osnet/dist/uts/common/fs/zfs/sys/dmu.h
@@ -957,13 +957,8 @@ typedef void (*dmu_traverse_cb_t)(objset
void dmu_traverse_objset(objset_t *os, uint64_t txg_start,
dmu_traverse_cb_t cb, void *arg);
-#ifdef __FreeBSD__
int dmu_diff(const char *tosnap_name, const char *fromsnap_name,
struct file *fp, offset_t *offp);
-#else
-int dmu_diff(const char *tosnap_name, const char *fromsnap_name,
- struct vnode *vp, offset_t *offp);
-#endif
/* CRC64 table */
#define ZFS_CRC64_POLY 0xC96C5795D7870F42ULL /* ECMA-182, reflected form */
diff -r 78bb594e351e -r f95f69bb5abe external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c
--- external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c
+++ external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c
@@ -5296,11 +5296,7 @@ zfs_ioc_diff(zfs_cmd_t *zc)
off = fp->f_offset;
-#ifdef __FreeBSD__
error = dmu_diff(zc->zc_name, zc->zc_value, fp, &off);
-#else
- error = dmu_diff(zc->zc_name, zc->zc_value, fp->f_vnode, &off);
-#endif
if (off >= 0 && off <= MAXOFFSET_T)
fp->f_offset = off;
--Apple-Mail=_263A2ADB-9D83-4DF5-A153-C9D927E63EA4--
--Apple-Mail=_FC1C4FEB-E02A-47BF-8CBB-D3C164AF2FC6
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE2BL3ha7Xao4WUZVYKoaVJdNr+uEFAl2hv5MACgkQKoaVJdNr
+uET/Qf/fq7ruOcwDpKuv3BgNfH+EP7nkBaMXRAkNiMF+01q5hBLVXuS4mxGdHCP
tx27pSSNRuY08LXyQeo/2T/JvJaLfR8u+ctrhWtIhe82M2wbPGEdh1Q0qX//TNXg
6gs9DHpFl0FXT9Dgs93dX4L81VoqIctnkzsEXPWTASPGYJkZuu3/MwV6WXUm7F5X
kM5QEpKalIJIMA2XoTVNv2F8raVzUzfzK0HwxwyeE1khP73i5n96dlov0mRFlgW+
c2Ny/Nan+bTPZnlGxAcMQFPZqnsCpmB1HTxO7I1OUs1jxzGq4g/8R5HVBWHlVOte
QYvEgmW0Bd7mMI3ozwrhHQ+Kmau4xA==
=h6J2
-----END PGP SIGNATURE-----
--Apple-Mail=_FC1C4FEB-E02A-47BF-8CBB-D3C164AF2FC6--
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Mon, 14 Oct 2019 13:49:23 +0100
On Sat, Oct 12, 2019 at 12:00:02PM +0000, J. Hannken-Illjes wrote:
> Should fix PR kern/54541: kernel panic using "zfs diff"
It does - thanks!
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
home 72.5K 1.23T 23K /home
# touch /home/hello
# zfs snapshot home@hello
# touch /home/world
# zfs snapshot home@world
# zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
home 96K 1.23T 23K /home
home@hello 13K - 23K -
home@world 0 - 23K -
# touch /home/after
# zfs diff home@world
M /home/
+ /home/after
# zfs diff home@hello home@world
M /home/
+ /home/world
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Mon, 14 Oct 2019 14:14:08 +0100
On the rump front, I'm pretty sure that select() ends up calling fd_getfile.
A quick test doesn't uncover any clues:
- take the example program from select(2)
- replace fd = 1 with fd = open("/dev/zero", O_RDONLY);
$ rump/fdscan
Data received on 1 file descriptor(s)
Data on file descriptor 5
$ export RUMPHIJACK=blanket=/dev/zero
$ rump/fdscan
Data received on 1 file descriptor(s)
Data on file descriptor 131
so no panic, but in the latter run fd_getfile gets called with 3, not 3+128=131.
From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54541 CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
Date: Mon, 14 Oct 2019 13:18:00 +0000
Module Name: src
Committed By: hannken
Date: Mon Oct 14 13:18:00 UTC 2019
Modified Files:
src/external/cddl/osnet/dist/uts/common/fs/zfs: dmu_diff.c zfs_ioctl.c
src/external/cddl/osnet/dist/uts/common/fs/zfs/sys: dmu.h
Log Message:
Change dmu_diff() back to use a "file" instead of a "vnode".
Command "zfs diff" calls it with a pipe, not a plain file.
Fixes PR kern/54541: kernel panic using "zfs diff"
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/dmu_diff.c
cvs rdiff -u -r1.20 -r1.21 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c
cvs rdiff -u -r1.3 -r1.4 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/sys/dmu.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Mon, 14 Oct 2019 15:25:39 +0200
--Apple-Mail=_41BB5830-A89E-4C6A-867F-D3F6F0C8FBB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> On 14. Oct 2019, at 15:15, Patrick Welche <prlw1@cam.ac.uk> wrote:
<snip>
> On the rump front, I'm pretty sure that select() ends up calling =
fd_getfile.
The problem is ZFS ioctl passing file descriptors through
its data. I'm pretty sure rump hijacking does not translate
these descriptors. It had to examine ioctl data but doesn't.
--
J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig
--Apple-Mail=_41BB5830-A89E-4C6A-867F-D3F6F0C8FBB9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE2BL3ha7Xao4WUZVYKoaVJdNr+uEFAl2kd1MACgkQKoaVJdNr
+uFwJwgAk8jF9eRL/g/hTht7nEn2OcjMX94FFKkTg4qxQpGzTj4SV9MLPC02lkNB
AWewdHI8mpyY4CRKfHzRMT++BEP08lbVPm1HMY843kY0yYFSrFioJyDdBCdOxvpz
ahACEIZ9OL4qT+Em84h8a4RkOV82+tXRg1mi4ALJwRYiI5EkwLaHxiHGfWa3t1kD
JL6QPd3QBLAg5tKnKDxnw0Pf9GMCIPZdIwgEqu4bj72nOI5KdUhP3ottweYc5RDm
oht0+jJbEjX2ILHbVRUb84mn7/PhcQgP873fFJ7RR6NJl/OUxt7IulEimXfPc0I5
alpVgupgBw8dxNUaN8KhrKhvcqh6nQ==
=UOtp
-----END PGP SIGNATURE-----
--Apple-Mail=_41BB5830-A89E-4C6A-867F-D3F6F0C8FBB9--
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54541 CVS commit: [netbsd-9] src/external/cddl/osnet/dist/uts/common/fs/zfs
Date: Tue, 15 Oct 2019 18:17:06 +0000
Module Name: src
Committed By: martin
Date: Tue Oct 15 18:17:06 UTC 2019
Modified Files:
src/external/cddl/osnet/dist/uts/common/fs/zfs [netbsd-9]: dmu_diff.c
zfs_ioctl.c
src/external/cddl/osnet/dist/uts/common/fs/zfs/sys [netbsd-9]: dmu.h
Log Message:
Pull up following revision(s) (requested by hannken in ticket #308):
external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c: revision 1.21
external/cddl/osnet/dist/uts/common/fs/zfs/dmu_diff.c: revision 1.3
external/cddl/osnet/dist/uts/common/fs/zfs/dmu_diff.c: revision 1.4
external/cddl/osnet/dist/uts/common/fs/zfs/sys/dmu.h: revision 1.4
Change dmu_diff() back to use a "file" instead of a "vnode".
Command "zfs diff" calls it with a pipe, not a plain file.
Fixes PR kern/54541: kernel panic using "zfs diff"
-
Add missing "#ifdef _KERNEL" to fix the build of userland zfs libraries.
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.2.6.1 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/dmu_diff.c
cvs rdiff -u -r1.20 -r1.20.2.1 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/zfs_ioctl.c
cvs rdiff -u -r1.3 -r1.3.4.1 \
src/external/cddl/osnet/dist/uts/common/fs/zfs/sys/dmu.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: =?UTF-8?Q?J=C3=B6rn_Clausen?= <joernc@posteo.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/54541: kernel panic using "zfs diff"
Date: Mon, 21 Oct 2019 13:23:04 +0200
I just tried my test-case with the daily release from October 17th, and=20
I can also report that "zfs diff" now works as expected.
Many thanks to Patrick, J=C3=BCrgen and all others involved in fixing this=
=2E
From my point of view, this PR can be closed.
--=20
Joern Clausen
https://www.oe-files.de/photography/
State-Changed-From-To: open->closed
State-Changed-By: prlw1@NetBSD.org
State-Changed-When: Tue, 05 Nov 2019 11:28:44 +0000
State-Changed-Why:
Bug fixed, rump behaviour explained, and fix pulled up to NetBSD 9 - thanks!
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.