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:

NetBSD Home
NetBSD PR Database Search

(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.