From nobody@FreeBSD.org  Mon Sep 13 22:06:13 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7FE501065694
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 13 Sep 2010 22:06:13 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 6E7978FC27
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 13 Sep 2010 22:06:13 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o8DM6CNw076661
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 13 Sep 2010 22:06:12 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o8DM6CQ9076660;
	Mon, 13 Sep 2010 22:06:12 GMT
	(envelope-from nobody)
Message-Id: <201009132206.o8DM6CQ9076660@www.freebsd.org>
Date: Mon, 13 Sep 2010 22:06:12 GMT
From: "Vladislav V. Prodan" <universite@ukr.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Panic, when viewing the list of ZFS snapshots
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         150544
>Category:       kern
>Synopsis:       [zfs] [panic] [patch] amd64 & i386 stable/8-ZFSv15 & HEAD-ZFSv15; Panic during ls(1) while in snapshot directories.
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    mm
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 13 22:10:01 UTC 2010
>Closed-Date:    Wed Sep 15 16:52:18 UTC 2010
>Last-Modified:  Wed Sep 15 16:52:18 UTC 2010
>Originator:     Vladislav V. Prodan
>Release:        9.0-CURRENT  amd64
>Organization:
>Environment:
FreeBSD solo.XXXXX.biz 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue Aug 24 15:52:21 EEST 2010     root@solo.XXXXX.biz:/usr/obj/usr/src/sys/solo.2  amd64

>Description:
FreeBSD 9.0-CURRENT #0: Tue Aug 24 15:52:21 EEST 2010 root

Kernel Version:                                 900017 (osreldate)

Hardware Platform:                              amd64
Processor Architecture:                         amd64

22:34  up 16 days,  7:01, 1 user, load averages: 0,00 0,00 0,00
------------------------------------------------------------------------

Physical Memory:                                4075.01M
Page Size:                                      4096

Kernel Memory
TOTAL:                                          138.30M
DATA:                                   91.34%  126.33M
TEXT:                                   8.66%   11.97M

ARC Summary
        Storage pool Version:                   15 (spa)
        Filesystem Version:                     4 (zpl)
        Memory Throttle Count:                  0

ARC Misc:
        Deleted:                                2756856
        Recycle Misses:                         4968834
        Mutex Misses:                           10542
        Evict Skips:                            10542

ARC Size:
        Current Size:                   88.31%  141.30M (arcsize)
        Target Size: (Adaptive)         91.87%  146.99M (c)
        Min Size (Hard Limit):          19.51%  31.22M (c_min)
        Max Size (High Water):          ~5:1    160.00M (c_max)

ARC Size Breakdown:
        Recently Used Cache Size:       93.72%  137.75M (p)
        Frequently Used Cache Size:     6.28%   9.24M (c-p)

ARC Hash Breakdown:
        Elements Max:                           24257
        Elements Current:               56.82%  13783
        Collisions:                             1388561
        Chain Max:                              5
        Chains:                                 1467

ARC Efficiency:
        Cache Access Total:                     25347525
        Cache Hit Ratio:                80.76%  20470182
        Cache Miss Ratio:               19.24%  4877343
        Actual Hit Ratio:               80.76%  20470182

        Data Demand Efficiency:         84.62%
        Data Prefetch Efficiency:       DISABLED (zfs_prefetch_disable)

        CACHE HITS BY CACHE LIST:
          Anonymous:                    --%     Counter Rolled.
          Most Recently Used:           13.30%  2721548 (mru)
          Most Frequently Used:         86.70%  17748634 (mfu)
          Most Recently Used Ghost:     1.45%   295890 (mru_ghost)
          Most Frequently Used Ghost:   11.09%  2269937 (mfu_ghost)

        CACHE HITS BY DATA TYPE:
          Demand Data:                  49.03%  10036630
          Prefetch Data:                0.00%   0
          Demand Metadata:              50.97%  10433552
          Prefetch Metadata:            0.00%   0

        CACHE MISSES BY DATA TYPE:
          Demand Data:                  37.41%  1824523
          Prefetch Data:                0.00%   0
          Demand Metadata:              62.59%  3052820
          Prefetch Metadata:            0.00%   0

L2 ARC Stats: (enabled with access > 0)         0

VDEV Cache Summary
        Access Total:                           3023322
        Hits Ratio:                     91.73%  2773221
        Miss Ratio:                     8.27%   250101
        Delegations:                            1638

ZFS Tunable (sysctl):
        kern.maxusers=512
        vfs.zfs.l2c_only_size=0
        vfs.zfs.mfu_ghost_data_lsize=5889024
        vfs.zfs.mfu_ghost_metadata_lsize=25750528
        vfs.zfs.mfu_ghost_size=31639552
        vfs.zfs.mfu_data_lsize=976896
        vfs.zfs.mfu_metadata_lsize=17408
        vfs.zfs.mfu_size=11664384
        vfs.zfs.mru_ghost_data_lsize=6066688
        vfs.zfs.mru_ghost_metadata_lsize=263168
        vfs.zfs.mru_ghost_size=6329856
        vfs.zfs.mru_data_lsize=1758720
        vfs.zfs.mru_metadata_lsize=167936
        vfs.zfs.mru_size=35749376
        vfs.zfs.anon_data_lsize=0
        vfs.zfs.anon_metadata_lsize=0
        vfs.zfs.anon_size=950272
        vfs.zfs.l2arc_norw=1
        vfs.zfs.l2arc_feed_again=1
        vfs.zfs.l2arc_noprefetch=0
        vfs.zfs.l2arc_feed_min_ms=200
        vfs.zfs.l2arc_feed_secs=1
        vfs.zfs.l2arc_headroom=2
        vfs.zfs.l2arc_write_boost=8388608
        vfs.zfs.l2arc_write_max=8388608
        vfs.zfs.arc_meta_limit=41943040
        vfs.zfs.arc_meta_used=144496184
        vfs.zfs.mdcomp_disable=0
        vfs.zfs.arc_min=32735232
        vfs.zfs.arc_max=167772160
        vfs.zfs.zfetch.array_rd_sz=1048576
        vfs.zfs.zfetch.block_cap=256
        vfs.zfs.zfetch.min_sec_reap=2
        vfs.zfs.zfetch.max_streams=8
        vfs.zfs.prefetch_disable=1
        vfs.zfs.check_hostid=1
        vfs.zfs.recover=0
        vfs.zfs.txg.write_limit_override=0
        vfs.zfs.txg.synctime=5
        vfs.zfs.txg.timeout=30
        vfs.zfs.scrub_limit=10
        vfs.zfs.vdev.cache.bshift=16
        vfs.zfs.vdev.cache.size=10485760
        vfs.zfs.vdev.cache.max=16384
        vfs.zfs.vdev.aggregation_limit=131072
        vfs.zfs.vdev.ramp_rate=2
        vfs.zfs.vdev.time_shift=6
        vfs.zfs.vdev.min_pending=4
        vfs.zfs.vdev.max_pending=10
        vfs.zfs.cache_flush_disable=0
        vfs.zfs.zil_disable=0
        vfs.zfs.zio.use_uma=0
        vfs.zfs.version.zpl=4
        vfs.zfs.version.spa=15
        vfs.zfs.version.dmu_backup_stream=1
        vfs.zfs.version.dmu_backup_header=2
        vfs.zfs.version.acl=1
        vfs.zfs.debug=0
        vfs.zfs.super_owner=0
        vm.kmem_size=1047527424
        vm.kmem_size_scale=3
        vm.kmem_size_min=0
        vm.kmem_size_max=1047527424




[1:01]solo:root->/root# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
tank                      10,8G   124G   601M  legacy
tank/backup               6,73G   124G  6,73G  /backup
tank/mysql                29,4M   124G  8,77M  /var/db/mysql
tank/mysql/ibdata         10,0M   124G  10,0M  /var/db/mysql/ibdata
tank/mysql/iblogs         10,2M   124G  10,0M  /var/db/mysql/iblogs
tank/tmp                   192K   124G   192K  /tmp
tank/usr                  2,51G   124G  1,64G  /usr
tank/usr/home               20K   124G    20K  /usr/home
tank/usr/ports             552M   124G   502M  /usr/ports
tank/usr/ports/distfiles  49,8M   124G  49,8M  /usr/ports/distfiles
tank/usr/src               336M   124G   336M  /usr/src
tank/var                   700M   124G   204K  /var
tank/var/crash            21,5K   124G  21,5K  /var/crash
tank/var/db               68,6M   124G  68,6M  /var/db
tank/var/empty              20K   124G    20K  /var/empty
tank/var/log              14,8M   124G  14,8M  /var/log
tank/var/mail               72K   124G    72K  /var/mail
tank/var/run              75,5K   124G  75,5K  /var/run
tank/var/tmp               616M   124G   616M  /var/tmp
tank/www                   234M   124G   234M  /www

>How-To-Repeat:
[0:50]solo:root->ftp/ncftp# zfs list -t snapshot
NAME                          USED  AVAIL  REFER  MOUNTPOINT
tank/mysql@yesterday          214K      -  8,81M  -
tank/mysql@today                 0      -  8,77M  -
tank/mysql/ibdata@yesterday      0      -  10,0M  -
tank/mysql/ibdata@today          0      -  10,0M  -
tank/mysql/iblogs@yesterday      0      -  10,0M  -
tank/mysql/iblogs@today          0      -  10,0M  -
[0:50]solo:root->ftp/ncftp# cd /var/db/mysql
[0:50]solo:root->db/mysql# cd .zfs
[0:50]solo:root->mysql/.zfs# ll

And the panic ...

http://img835.imageshack.us/img835/1779/capture09142010005524.jpg
>Fix:


>Release-Note:
>Audit-Trail:

From: jhell <jhell@DataIX.net>
To: "Vladislav V. Prodan" <universite@ukr.net>
Cc:  
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 01:56:36 -0400

 This is a multi-part message in MIME format.
 --------------000303020304060701070902
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 09/13/2010 18:06, Vladislav V. Prodan wrote:
 >> Number:         150544
 >> Category:       kern
 >> Synopsis:       Panic, when viewing the list of ZFS snapshots
 >> Confidential:   no
 >> Severity:       non-critical
 >> Priority:       low
 >> Responsible:    freebsd-bugs
 >> State:          open
 >> Quarter:        
 >> Keywords:       
 >> Date-Required:
 >> Class:          sw-bug
 >> Submitter-Id:   current-users
 >> Arrival-Date:   Mon Sep 13 22:10:01 UTC 2010
 >> Closed-Date:
 >> Last-Modified:
 >> Originator:     Vladislav V. Prodan
 >> Release:        9.0-CURRENT  amd64
 >> Organization:
 >> Environment:
 > 
 > http://img835.imageshack.us/img835/1779/capture09142010005524.jpg
 >> Fix: *UNKNOWN*
 > 
 
 Priority of this should be changed to *HIGH* & Severity changed to
 *Critical*.
 
 New synopsis: [ZFS][HIGH][CRIT] amd64 & i386 stable/8-ZFSv15 &
 HEAD-ZFSv15, Panic, during ls(1) while in snapshot directories.
 
 People BCC'd, pjd@ mm@ avg@ stable@ current@ to grab some more attention.
 
 Backtraces: I have two available vmcore.37 & 38 along with core.txt.37 & 38.
 
 Backtrace 37 attached.
 
 Background: Because a normal user can access snapshot directories(.zfs)
 they have the ability to crash a machine running HEAD or stable/8 with
 ZFSv15 patches.
 
 Workaround: Do not snapshot global readable directories or chmod go-rwx
 /path/to where the snapshot directory (.zfs) is.
 
 Systems effected thus far:
 FreeBSD/i386 8.1-STABLE r212590M (ZFSv15 patches)
 FreeBSD 9.0-CURRENT ? ?
 Possibly 8.1-RELEASE (ZFSv15 patches)
 
 
 Regards,
 
 - -- 
 
  jhell,v
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.16 (FreeBSD)
 
 iQEcBAEBAgAGBQJMjw6UAAoJEJBXh4mJ2FR+JUUH/jEQ3NRYhwedW1dbSTNb0bvr
 LHEWoBz1S+sOERzu5Qlu4Q7QLvbOp2qiUfTmf120DedgxyTKlsRc45I90X7RCp8E
 LuqfHO6n3aVuXO/9luwqUzHYIgI8KVUTDTiN3wa7HB89NYbpe2BRVhJo16QXoQCf
 emDXtOcdX7DJWsetrdeTJ/zdCWG1tkEjVtM1KATVLOvx4QXfvxvgYISvGFXPdCWm
 Cuzb6GoQ/qtSH+dMQKNUppcvhllJRG/uEV0ot0XL35tI3Cj5f5dJqfqAu+kNkGrT
 eZPbeuDghcFFyK+uLgb9CdGzxAj8k0sJoGL2bOKqC/ZTyYnbNrvN01nA6E2zEsw=
 =5Ujk
 -----END PGP SIGNATURE-----
 
 --------------000303020304060701070902
 Content-Type: text/plain;
  name="backtrace.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="backtrace.txt"
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address	= 0x80
 fault code		= supervisor read, page not present
 instruction pointer	= 0x20:0x80922145
 stack pointer	        = 0x28:0xb4593738
 frame pointer	        = 0x28:0xb4593748
 code segment		= base 0x0, limit 0xfffff, type 0x1b
 			= DPL 0, pres 1, def32 1, gran 1
 processor eflags	= interrupt enabled, resume, IOPL = 0
 current process		= 7073 (ls)
 trap number		= 12
 panic: page fault
 cpuid = 0
 KDB: stack backtrace:
 db_trace_self_wrapper(8098bd66,b45935d8,80669da9,809ae1aa,0,...) at 0x804e1e38 = db_trace_self_wrapper+0x26
 kdb_backtrace(809ae1aa,0,8096e958,b45935e4,0,...) at 0x8069652a = kdb_backtrace+0x29
 panic(8096e958,809af581,92eec168,1,1,...) at 0x80669da9 = panic+0x114
 trap_fatal(87c10570,0,1,0,8ebdf074,...) at 0x8090cca7 = trap_fatal+0x320
 trap_pfault(8a01,b459368c,81673760,b45936a4,92c997f8,...) at 0x8090ceef = trap_pfault+0x23c
 trap(b45936f8) at 0x8090d7c7 = trap+0x3f9
 calltrap() at 0x808f0f0c = calltrap+0x6
 --- trap 0xc, eip = 0x80922145, esp = 0xb4593738, ebp = 0xb4593748 ---
 VOP_LOCK1_APV(80d0fea0,b459375c,b459375c,80a13f80,8b65da78,...) at 0x80922145 = VOP_LOCK1_APV+0x3e
 _vn_lock(8b65da78,80400,80cee192,1b5,8b65da78,...) at 0x806fdfbc = _vn_lock+0x3d
 gfs_file_create(54,86e1c53c,86d90000,80d0fea0,18,...) at 0x80c08ea6 = gfs_file_create+0x65
 gfs_dir_create(54,86e1c53c,86d90000,80d0fea0,0,...) at 0x80c08f2d = gfs_dir_create+0x2c
 zfsctl_mknode_shares(86e1c53c,80cee192,308,356,925c2bdc,...) at 0x80c82773 = zfsctl_mknode_shares+0x52
 gfs_dir_lookup(86e1c53c,b45938c0,b4593b74,888e8700,0,...) at 0x80c08d69 = gfs_dir_lookup+0x216
 zfsctl_root_lookup(86e1c53c,b45938c0,b4593b74,0,0,...) at 0x80c829f1 = zfsctl_root_lookup+0x10a
 zfsctl_freebsd_root_lookup(b4593a34,b45939e8,200000,b4593b88,b4593a54,...) at 0x80c83029 = zfsctl_freebsd_root_lookup+0xb0
 VOP_LOOKUP_APV(80cfbb00,b4593a34,809908ef,1f6,0,...) at 0x80922801 = VOP_LOOKUP_APV+0x48
 lookup(b4593b5c,87e53800,400,b4593b7c,0,...) at 0x806e59b4 = lookup+0x5fb
 namei(b4593b5c,b4593afc,60,0,92eec000,...) at 0x806e68ce = namei+0x57d
 kern_statat_vnhook(92eec000,200,ffffff9c,304043b8,0,...) at 0x806f6269 = kern_statat_vnhook+0x6c
 kern_statat(92eec000,200,ffffff9c,304043b8,0,...) at 0x806f63d3 = kern_statat+0x3c
 kern_lstat(92eec000,304043b8,0,b4593c18,5188ce43,...) at 0x806f640b = kern_lstat+0x36
 lstat(92eec000,b4593cf8,c,c,c,...) at 0x806f649f = lstat+0x2b
 syscall(b4593d38) at 0x8090d1b8 = syscall+0x2ab
 Xint0x80_syscall() at 0x808f0f71 = Xint0x80_syscall+0x21
 --- syscall (190, FreeBSD ELF32, lstat), eip = 0x301c3f73, esp = 0x7fbfe54c, ebp = 0x7fbfe5d8 ---
 Uptime: 1h2m13s
 Physical memory: 1009 MB
 Dumping 458 MB: 443 427 411 395 379 363 347 331 315 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11
 
 Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/linprocfs.ko
 Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/linux.ko
 Reading symbols from /boot/kernel/linsysfs.ko...Reading symbols from /boot/kernel/linsysfs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/linsysfs.ko
 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/zfs.ko
 Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/opensolaris.ko
 Reading symbols from /boot/kernel/lindev.ko...Reading symbols from /boot/kernel/lindev.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/lindev.ko
 Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/aio.ko
 Reading symbols from /boot/kernel/cpufreq.ko...Reading symbols from /boot/kernel/cpufreq.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/cpufreq.ko
 Reading symbols from /boot/kernel/ksyms.ko...Reading symbols from /boot/kernel/ksyms.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ksyms.ko
 Reading symbols from /boot/kernel/mqueuefs.ko...Reading symbols from /boot/kernel/mqueuefs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/mqueuefs.ko
 #0  doadump () at pcpu.h:231
 231	pcpu.h: No such file or directory.
 	in pcpu.h
 (kgdb) #0  doadump () at pcpu.h:231
 #1  0x80669b51 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
 #2  0x80669de5 in panic (fmt=Variable "fmt" is not available.
 ) at /usr/src/sys/kern/kern_shutdown.c:590
 #3  0x8090cca7 in trap_fatal (frame=0xb45936f8, eva=128)
     at /usr/src/sys/i386/i386/trap.c:938
 #4  0x8090ceef in trap_pfault (frame=0xb45936f8, usermode=0, eva=128)
     at /usr/src/sys/i386/i386/trap.c:851
 #5  0x8090d7c7 in trap (frame=0xb45936f8) at /usr/src/sys/i386/i386/trap.c:533
 #6  0x808f0f0c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
 #7  0x80922145 in VOP_LOCK1_APV (vop=0x0, a=0xb459375c) at vnode_if.c:1986
 #8  0x806fdfbc in _vn_lock (vp=0x8b65da78, flags=525312, 
     file=0x80cee192 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c", line=437) at vnode_if.h:859
 #9  0x80c08ea6 in gfs_file_create (size=84, pvp=0x86e1c53c, vfsp=0x86d90000, 
     ops=0x80d0fea0)
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:437
 #10 0x80c08f2d in gfs_dir_create (struct_size=84, pvp=0x86e1c53c, 
     vfsp=0x86d90000, ops=0x80d0fea0, entries=0x0, inode_cb=0, maxlen=256, 
     readdir_cb=0, lookup_cb=0)
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:496
 #11 0x80c82773 in zfsctl_mknode_shares (pvp=0x86e1c53c)
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:1146
 #12 0x80c08d69 in gfs_dir_lookup (dvp=0x86e1c53c, nm=0xb45938c0 "shares", 
     vpp=0xb4593b74, cr=0x888e8700, flags=0, direntflags=0x0, realpnp=0x0)
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:777
 #13 0x80c829f1 in zfsctl_root_lookup (dvp=0x86e1c53c, nm=0xb45938c0 "shares", 
     vpp=0xb4593b74, pnp=0x0, flags=Variable "flags" is not available.
 )
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:506
 #14 0x80c83029 in zfsctl_freebsd_root_lookup (ap=0xb4593a34)
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:541
 #15 0x80922801 in VOP_LOOKUP_APV (vop=0x80cfbb00, a=0xb4593a34)
     at vnode_if.c:123
 #16 0x806e59b4 in lookup (ndp=0xb4593b5c) at vnode_if.h:54
 #17 0x806e68ce in namei (ndp=0xb4593b5c) at /usr/src/sys/kern/vfs_lookup.c:269
 #18 0x806f6269 in kern_statat_vnhook (td=0x92eec000, flag=512, fd=-100, 
     path=0x304043b8 <Address 0x304043b8 out of bounds>, 
     pathseg=UIO_USERSPACE, sbp=0xb4593c18, hook=0)
     at /usr/src/sys/kern/vfs_syscalls.c:2346
 #19 0x806f63d3 in kern_statat (td=0x92eec000, flag=512, fd=-100, 
     path=0x304043b8 <Address 0x304043b8 out of bounds>, 
     pathseg=UIO_USERSPACE, sbp=0xb4593c18)
     at /usr/src/sys/kern/vfs_syscalls.c:2327
 #20 0x806f640b in kern_lstat (td=0x92eec000, 
     path=0x304043b8 <Address 0x304043b8 out of bounds>, 
     pathseg=UIO_USERSPACE, sbp=0xb4593c18)
     at /usr/src/sys/kern/vfs_syscalls.c:2400
 #21 0x806f649f in lstat (td=0x92eec000, uap=0xb4593cf8)
     at /usr/src/sys/kern/vfs_syscalls.c:2390
 #22 0x8090d1b8 in syscall (frame=0xb4593d38)
     at /usr/src/sys/i386/i386/trap.c:1111
 #23 0x808f0f71 in Xint0x80_syscall ()
     at /usr/src/sys/i386/i386/exception.s:264
 #24 0x00000033 in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 (kgdb) 
 
 --------------000303020304060701070902
 Content-Type: application/octet-stream;
  name="backtrace.txt.sig"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="backtrace.txt.sig"
 
 iQEcBAABAgAGBQJMjw6UAAoJEJBXh4mJ2FR+pk4H/22ORXAmvGRUZIf11X0Doc66WQndsI+D
 2dwQIBwSDs7DWXqt98A2g0w8I7ZfleZdSUeOBpQXifncG5MsMqS7Abhl9PoGUsMTubH0R6Gv
 +0wUYP+Nt607mOsKk46lG3FyrG2W4yt6h9fInJ3/NOY8nHaJOIZz3i/KS+5/SoRsWCPqVoH+
 sZVgBjErAnyDfeoqq9ZTVgJJtG5tnjdxUmKHFB07FzZDwUlpwx/2l7PcBQUNWch8wqZSveTN
 zB4KdTTCOMaRsSOQDb74JoF9lecb2+bLHapzg0xWKp3MIrmpqE9nSr4nXEKlL2OaqApfDxFC
 tMQ2a+qtAeU3USDDmW2mnKk=
 --------------000303020304060701070902--

From: Andriy Gapon <avg@icyb.net.ua>
To: jhell <jhell@DataIX.net>
Cc: "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@FreeBSD.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 09:19:09 +0300

 on 14/09/2010 08:56 jhell said the following:
 > Priority of this should be changed to *HIGH* & Severity changed to
 > *Critical*.
 > 
 > New synopsis: [ZFS][HIGH][CRIT] amd64 & i386 stable/8-ZFSv15 &
 > HEAD-ZFSv15, Panic, during ls(1) while in snapshot directories.
 > 
 > People BCC'd, pjd@ mm@ avg@ stable@ current@ to grab some more attention.
 > 
 > Backtraces: I have two available vmcore.37 & 38 along with core.txt.37 & 38.
 > 
 > Backtrace 37 attached.
 > 
 > Background: Because a normal user can access snapshot directories(.zfs)
 > they have the ability to crash a machine running HEAD or stable/8 with
 > ZFSv15 patches.
 > 
 > Workaround: Do not snapshot global readable directories or chmod go-rwx
 > /path/to where the snapshot directory (.zfs) is.
 > 
 > Systems effected thus far:
 > FreeBSD/i386 8.1-STABLE r212590M (ZFSv15 patches)
 > FreeBSD 9.0-CURRENT ? ?
 > Possibly 8.1-RELEASE (ZFSv15 patches)
 
 Looks like unimplemented vop_lock1.
 I think that default implementation usually comes in via default_vnodeops, but
 can be locally overridden.
 What kind of a vnode is this?  Can you print *vp in e.g. frame 8?
 
 -- 
 Andriy Gapon

From: Andriy Gapon <avg@freebsd.org>
To: jhell <jhell@DataIX.net>, Pawel Jakub Dawidek <pjd@freebsd.org>
Cc: "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 09:26:54 +0300

 on 14/09/2010 09:19 Andriy Gapon said the following:
 > Looks like unimplemented vop_lock1.
 > I think that default implementation usually comes in via default_vnodeops, but
 > can be locally overridden.
 > What kind of a vnode is this?  Can you print *vp in e.g. frame 8?
 > 
 
 Hmm, very strange, zfsctl_mknode_shares() passes zfsctl_ops_shares as a new
 vop_vector to gfs_dir_create(), but I don't see zfsctl_ops_shares being
 populated with actual vnode operations anywhere.
 
 -- 
 Andriy Gapon

From: Andriy Gapon <avg@freebsd.org>
To: jhell <jhell@DataIX.net>, Pawel Jakub Dawidek <pjd@freebsd.org>
Cc: "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 09:35:40 +0300

 on 14/09/2010 09:26 Andriy Gapon said the following:
 > on 14/09/2010 09:19 Andriy Gapon said the following:
 >> Looks like unimplemented vop_lock1.
 >> I think that default implementation usually comes in via default_vnodeops, but
 >> can be locally overridden.
 >> What kind of a vnode is this?  Can you print *vp in e.g. frame 8?
 >>
 > 
 > Hmm, very strange, zfsctl_mknode_shares() passes zfsctl_ops_shares as a new
 > vop_vector to gfs_dir_create(), but I don't see zfsctl_ops_shares being
 > populated with actual vnode operations anywhere.
 > 
 
 Maybe this happens because we don't really support .zfs/shares, but create (or
 try to create) that directory for some reason?
 
 -- 
 Andriy Gapon

From: jhell <jhell@DataIX.net>
To: Andriy Gapon <avg@icyb.net.ua>
Cc: "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@FreeBSD.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 02:38:25 -0400

 This is a multi-part message in MIME format.
 --------------020706070406080404040902
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 09/14/2010 02:19, Andriy Gapon wrote:
 > Looks like unimplemented vop_lock1.
 > I think that default implementation usually comes in via default_vnodeops, but
 > can be locally overridden.
 > What kind of a vnode is this?  Can you print *vp in e.g. frame 8?
 
 Attached.
 
 
 Thanks for looking into this.
 
 - -- 
 
  jhell,v
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.16 (FreeBSD)
 
 iQEcBAEBAgAGBQJMjxhhAAoJEJBXh4mJ2FR+MKoH/3ZYaMTER5MV21fVSVS2RnJE
 qNr00bTH2N/zldFK871vPTxbkD0SfG21qf4v22/VJmYk5EFOtN+/uDsM4osha3a0
 6mxgxYfWXWDtLSg6+2SVtdYF60RWIFn6H5zyLZCZGjcf5SnjT1QTBu/SG2BthM97
 PUMGPxW+8T+Ae0ZWWXNB2BKtStirqlXaZCPyMU8IwQ52WLjcycmo4C7MT+U/LB+V
 7XoK/95LBjUuJ2uKKSEQNGjcJPUO1HRHcVePioWDFNbTN8tswZewzRUh9rVwz2SN
 C4hbMLIs9FWCl+52tTp6ve1aAfG5YvfGeT74I9Qkwoi3uMA84HPva6BtJP5Plvk=
 =gA5H
 -----END PGP SIGNATURE-----
 
 --------------020706070406080404040902
 Content-Type: text/plain;
  name="vp.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="vp.txt"
 
 #8  0x806fdfbc in _vn_lock (vp=0x8b65da78, flags=525312, 
     file=0x80cee192 "/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c", 
     line=437) at vnode_if.h:859
 859     vnode_if.h: No such file or directory.
         in vnode_if.h
 (kgdb) p *vp
 $1 = {v_type = VNON, v_tag = 0x80cf5f8d "zfs", v_op = 0x80d0fea0, v_data = 0x0, v_mount = 0x0, 
   v_nmntvnodes = {tqe_next = 0x0, tqe_prev = 0x0}, v_un = {vu_mount = 0x0, vu_socket = 0x0, 
     vu_cdev = 0x0, vu_fifoinfo = 0x0, vu_yield = 0}, v_hashlist = {le_next = 0x0, le_prev = 0x0}, 
   v_hash = 0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, 
     tqh_last = 0x8b65daa8}, v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, 
   v_lock = {lock_object = {lo_name = 0x80cf5f8d "zfs", lo_flags = 91422728, lo_data = 0, 
       lo_witness = 0x0}, lk_lock = 1, lk_timo = 51, lk_pri = 80}, v_interlock = {lock_object = {
       lo_name = 0x80991811 "vnode interlock", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, 
     mtx_lock = 4}, v_vnlock = 0x8b65dad0, v_holdcnt = 1, v_usecount = 1, v_iflag = 0, v_vflag = 0, 
   v_writecount = 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, v_bufobj = {bo_mtx = {
       lock_object = {lo_name = 0x80991821 "bufobj interlock", lo_flags = 16973824, lo_data = 0, 
         lo_witness = 0x0}, mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, 
         tqh_last = 0x8b65db34}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, 
         tqh_last = 0x8b65db44}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, 
     bo_ops = 0x809ed6c0, bo_bsize = 65536, bo_object = 0x0, bo_synclist = {le_next = 0x0, 
       le_prev = 0x0}, bo_private = 0x8b65da78, __bo_vnode = 0x8b65da78}, v_pollinfo = 0x0, 
   v_label = 0x0, v_lockf = 0x0}
 
 --------------020706070406080404040902
 Content-Type: application/octet-stream;
  name="vp.txt.sig"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="vp.txt.sig"
 
 iQEcBAABAgAGBQJMjxhhAAoJEJBXh4mJ2FR+Ft0H/jHa9zkDcw23fQUMxxx/FKaqXwRv8oI1
 sE0+oKuF108AREJt+UKRiQcyFtX2RwzPeeNcarMt5vf9mUPnCMDF1P6hriyFTGDEOm5M3/Ih
 XLOaCpm2iHDYcsBR98WSdYug+6CcQirMq6vOmu+seqp9vb8VRP3Wskcgzb9cKHl42YXQf05p
 0E5kEYq82ICuWqaZ5B3ZzXfWYDi7obU9ALLVuoS4Ajp/SuBbO3zTp+D3bppDLgwm2wgFzYCA
 LBYKe482nmrIh9GhDsAiYymn/oLcrKosVhn6VfJiqao6xFe5sa6W9/Sj0JYgDG5ggXkZV+B6
 e5Dmmc9qf0Njyxy9ugfBAFo=
 --------------020706070406080404040902--

From: Andriy Gapon <avg@freebsd.org>
To: jhell <jhell@DataIX.net>, Pawel Jakub Dawidek <pjd@freebsd.org>
Cc: "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 10:25:36 +0300

 on 14/09/2010 09:35 Andriy Gapon said the following:
 > 
 > Maybe this happens because we don't really support .zfs/shares, but create (or
 > try to create) that directory for some reason?
 > 
 
 Could you please test this patch?
 
 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 @@ -128,7 +128,6 @@ static int zfsctl_unmount_snap
   */
  static gfs_dirent_t zfsctl_root_entries[] = {
  	{ "snapshot", zfsctl_mknode_snapdir, GFS_CACHE_VNODE },
 -	{ "shares", zfsctl_mknode_shares, GFS_CACHE_VNODE },
  	{ NULL }
  };
 
 
 -- 
 Andriy Gapon

From: jhell <jhell@DataIX.net>
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc: Andriy Gapon <avg@FreeBSD.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@FreeBSD.org, mm@FreeBSD.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 04:06:34 -0400

 This is a multi-part message in MIME format.
 --------------030503050309090403030104
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 09/14/2010 03:45, Pawel Jakub Dawidek wrote:
 > On Tue, Sep 14, 2010 at 10:25:36AM +0300, Andriy Gapon wrote:
 >> on 14/09/2010 09:35 Andriy Gapon said the following:
 >>>
 >>> Maybe this happens because we don't really support .zfs/shares, but create (or
 >>> try to create) that directory for some reason?
 >>>
 >>
 >> Could you please test this patch?
 > 
 > The problem was introduced AFAIK by Martin's import of v15. I think it
 > is handled in my v28 properly, but would need to double check. All in
 > all, I'd prefer if Martin could handle the problem, as I wasn't involved
 > in v15 and it is hard to say for me in what shape it is and what bits
 > are missing (Martin CCed).
 > 
 >> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 >> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 >> @@ -128,7 +128,6 @@ static int zfsctl_unmount_snap
 >>   */
 >>  static gfs_dirent_t zfsctl_root_entries[] = {
 >>  	{ "snapshot", zfsctl_mknode_snapdir, GFS_CACHE_VNODE },
 >> -	{ "shares", zfsctl_mknode_shares, GFS_CACHE_VNODE },
 >>  	{ NULL }
 >>  };
 > 
 
 Andriy,
 	That patch-up did solve it. As for what those shares directories are
 good for I am not sure. Do they effect the sharenfs properties at all ?.
 If so then I know to not apply this and to just not ls(1) or cd(1) that
 directory until a more proper fix has been applied.
 
 
 Pawel,
 	Alright future replies if I am reading into it correctly, you will be
 removed from CC. Thank you for listening && looking in.
 
 
 Regards & Thanks again,
 
 - -- 
 
  jhell,v
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.16 (FreeBSD)
 
 iQEcBAEBAgAGBQJMjy0KAAoJEJBXh4mJ2FR+PJQH/ilvW5b3jdCKDU1kLA1YcEvt
 bxcJF5aCNBxKzkM8HBVnTbnQ4yQLrR7EMFZxDeAnkY4heim0+A5K1+FCEtCsPb3t
 UJfXDAqrbhqeVctvTI/gl1fErd/3N+9WUPwgDcBwgFLFLBmBdMbb3G5LpF6Hekvz
 y7/s+IoyC2i2klrtDkoor6UrJk3mLKuanBJdflgANElM/N9a4GW3JhaxiYLOpS7O
 M2iN84OuTydfZwCxWQhD+Rc8+29RdzyAylmupOao+/t622g1Pxn0rh6TH0wJmCJx
 MWBTNZhTK5ZUqlxVVgrekjlkyhAWFNxzXqdD/BO2gkCKRPnadxq1P1sEmxBcMLY=
 =vWVW
 -----END PGP SIGNATURE-----
 
 --------------030503050309090403030104
 Content-Type: text/plain;
  name="fc15fbef472b.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="fc15fbef472b.txt"
 
 changeset:   222:fc15fbef472b
 tag:         tip
 user:        J. Hellenthal <jhell@DataIX.net>
 date:        Tue Sep 14 03:57:52 2010 -0400
 summary:     PR/150544 Removed per Andriy, [SOLVED] 10/09/14
 
 diff -r 6cc9c3ffb5d8 -r fc15fbef472b sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	Mon Sep 13 22:27:27 2010 -0400
 +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	Tue Sep 14 03:57:52 2010 -0400
 @@ -128,7 +128,10 @@
   */
  static gfs_dirent_t zfsctl_root_entries[] = {
  	{ "snapshot", zfsctl_mknode_snapdir, GFS_CACHE_VNODE },
 -	{ "shares", zfsctl_mknode_shares, GFS_CACHE_VNODE },
 +	/* 
 +	 * PR/150544 Removed per Andriy, [SOLVED] 10/09/14
 +	 * { "shares", zfsctl_mknode_shares, GFS_CACHE_VNODE },
 +	 */
  	{ NULL }
  };
  
 
 
 --------------030503050309090403030104
 Content-Type: application/octet-stream;
  name="fc15fbef472b.txt.sig"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="fc15fbef472b.txt.sig"
 
 iQEcBAABAgAGBQJMjy0KAAoJEJBXh4mJ2FR+7aoIAIzCd45jbnB67sUHVygJkao/+8S68XUz
 LENk87Mds7tlIu/uHhTbDdefbMGVIhI2JH4dXJb9Rr3P6yZDIO5PqAGeyGStF0No2gi/2YvQ
 7rp0Gl9Wq0viXE0dVrO31lUzPBbFja8H0p8Muy+VvK1olIeRopuHWKoAtdH87aF1Ga79F7yI
 JKV524smqEC37ia/KF1M4RQzN0A5jHk7kNgRCQOnxglOEQCnch+rpHhYWhSo/n+2AxC1F99w
 7GqR/EJTxyvZAZ+dAXdXvEz66UORM1+f7ijSFEhefc6ajo1YTojiQH3CYKEXogQXBebCdoW7
 MVYUe0Mdo3SstWhdQoNfrmM=
 --------------030503050309090403030104--

From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: jhell <jhell@DataIX.net>
Cc: Andriy Gapon <avg@FreeBSD.org>,
	"Vladislav V. Prodan" <universite@ukr.net>,
	bug-followup@FreeBSD.org, mm@FreeBSD.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 10:08:20 +0200

 --rMWmSaSbD7nr+du9
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Sep 14, 2010 at 04:06:34AM -0400, jhell wrote:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 >=20
 > On 09/14/2010 03:45, Pawel Jakub Dawidek wrote:
 > > On Tue, Sep 14, 2010 at 10:25:36AM +0300, Andriy Gapon wrote:
 > >> on 14/09/2010 09:35 Andriy Gapon said the following:
 > >>>
 > >>> Maybe this happens because we don't really support .zfs/shares, but c=
 reate (or
 > >>> try to create) that directory for some reason?
 > >>>
 > >>
 > >> Could you please test this patch?
 > >=20
 > > The problem was introduced AFAIK by Martin's import of v15. I think it
 > > is handled in my v28 properly, but would need to double check. All in
 > > all, I'd prefer if Martin could handle the problem, as I wasn't involved
 > > in v15 and it is hard to say for me in what shape it is and what bits
 > > are missing (Martin CCed).
 > >=20
 > >> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 > >> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 > >> @@ -128,7 +128,6 @@ static int zfsctl_unmount_snap
 > >>   */
 > >>  static gfs_dirent_t zfsctl_root_entries[] =3D {
 > >>  	{ "snapshot", zfsctl_mknode_snapdir, GFS_CACHE_VNODE },
 > >> -	{ "shares", zfsctl_mknode_shares, GFS_CACHE_VNODE },
 > >>  	{ NULL }
 > >>  };
 > >=20
 >=20
 > Andriy,
 > 	That patch-up did solve it. As for what those shares directories are
 > good for I am not sure. Do they effect the sharenfs properties at all ?.
 > If so then I know to not apply this and to just not ls(1) or cd(1) that
 > directory until a more proper fix has been applied.
 >=20
 >=20
 > Pawel,
 > 	Alright future replies if I am reading into it correctly, you will be
 > removed from CC. Thank you for listening && looking in.
 
 I'm happy to be kept on CC, as some of your finding might be interesting
 for v28.
 
 --=20
 Pawel Jakub Dawidek                       http://www.wheelsystems.com
 pjd@FreeBSD.org                           http://www.FreeBSD.org
 FreeBSD committer                         Am I Evil? Yes, I Am!
 
 --rMWmSaSbD7nr+du9
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.14 (FreeBSD)
 
 iEYEARECAAYFAkyPLXQACgkQForvXbEpPzRiawCfT7nl3fVGDsASB4+jJqihajFU
 HPcAoN3ygUcA8JxW2u/O0CAjicl2Jvpw
 =CduR
 -----END PGP SIGNATURE-----
 
 --rMWmSaSbD7nr+du9--

From: Martin Matuska <mm@FreeBSD.org>
To: jhell <jhell@DataIX.net>
Cc: Pawel Jakub Dawidek <pjd@FreeBSD.org>, Andriy Gapon <avg@FreeBSD.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@FreeBSD.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 10:15:02 +0200

 This is a multi-part message in MIME format.
 --------------050904040905030901040700
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit
 
 There was one important line missing from the merge from pjd's p4 branch.
 
 Please confirm if this patch works and I will commit it ASAP.
 
 Dňa 14. 9. 2010 10:06, jhell  wrote / napísal(a):
 > On 09/14/2010 03:45, Pawel Jakub Dawidek wrote:
 >> On Tue, Sep 14, 2010 at 10:25:36AM +0300, Andriy Gapon wrote:
 >>> on 14/09/2010 09:35 Andriy Gapon said the following:
 >>>>
 >>>> Maybe this happens because we don't really support .zfs/shares, but create (or
 >>>> try to create) that directory for some reason?
 >>>>
 >>>
 >>> Could you please test this patch?
 > 
 >> The problem was introduced AFAIK by Martin's import of v15. I think it
 >> is handled in my v28 properly, but would need to double check. All in
 >> all, I'd prefer if Martin could handle the problem, as I wasn't involved
 >> in v15 and it is hard to say for me in what shape it is and what bits
 >> are missing (Martin CCed).
 > 
 >>> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 >>> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 >>> @@ -128,7 +128,6 @@ static int zfsctl_unmount_snap
 >>>   */
 >>>  static gfs_dirent_t zfsctl_root_entries[] = {
 >>>  	{ "snapshot", zfsctl_mknode_snapdir, GFS_CACHE_VNODE },
 >>> -	{ "shares", zfsctl_mknode_shares, GFS_CACHE_VNODE },
 >>>  	{ NULL }
 >>>  };
 > 
 > 
 > Andriy,
 > 	That patch-up did solve it. As for what those shares directories are
 > good for I am not sure. Do they effect the sharenfs properties at all ?.
 > If so then I know to not apply this and to just not ls(1) or cd(1) that
 > directory until a more proper fix has been applied.
 > 
 > 
 > Pawel,
 > 	Alright future replies if I am reading into it correctly, you will be
 > removed from CC. Thank you for listening && looking in.
 > 
 > 
 > Regards & Thanks again,
 > 
 
 --------------050904040905030901040700
 Content-Type: text/plain;
  name="zfs_ctldir.c.patch"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="zfs_ctldir.c.patch"
 
 SW5kZXg6IHN5cy9jZGRsL2NvbnRyaWIvb3BlbnNvbGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMv
 emZzX2N0bGRpci5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9jZGRsL2NvbnRyaWIvb3BlbnNv
 bGFyaXMvdXRzL2NvbW1vbi9mcy96ZnMvemZzX2N0bGRpci5jCShyZXZpc2lvbiAyMTI0OTEp
 CisrKyBzeXMvY2RkbC9jb250cmliL29wZW5zb2xhcmlzL3V0cy9jb21tb24vZnMvemZzL3pm
 c19jdGxkaXIuYwkod29ya2luZyBjb3B5KQpAQCAtMTE0OSw2ICsxMTQ5LDcgQEAKIAkgICAg
 TlVMTCwgTlVMTCk7CiAJc2RwID0gdnAtPnZfZGF0YTsKIAlzZHAtPnpjX2NtdGltZSA9ICgo
 emZzY3RsX25vZGVfdCAqKXB2cC0+dl9kYXRhKS0+emNfY210aW1lOworCVZPUF9VTkxPQ0so
 dnAsIDApOwogCXJldHVybiAodnApOwogCiB9Cg==
 --------------050904040905030901040700--

From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: Andriy Gapon <avg@freebsd.org>
Cc: jhell <jhell@DataIX.net>, "Vladislav V. Prodan" <universite@ukr.net>,
	bug-followup@freebsd.org, mm@FreeBSD.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 09:45:37 +0200

 --MGYHOYXEY6WxJCY8
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Sep 14, 2010 at 10:25:36AM +0300, Andriy Gapon wrote:
 > on 14/09/2010 09:35 Andriy Gapon said the following:
 > >=20
 > > Maybe this happens because we don't really support .zfs/shares, but cre=
 ate (or
 > > try to create) that directory for some reason?
 > >=20
 >=20
 > Could you please test this patch?
 
 The problem was introduced AFAIK by Martin's import of v15. I think it
 is handled in my v28 properly, but would need to double check. All in
 all, I'd prefer if Martin could handle the problem, as I wasn't involved
 in v15 and it is hard to say for me in what shape it is and what bits
 are missing (Martin CCed).
 
 > --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 > +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 > @@ -128,7 +128,6 @@ static int zfsctl_unmount_snap
 >   */
 >  static gfs_dirent_t zfsctl_root_entries[] =3D {
 >  	{ "snapshot", zfsctl_mknode_snapdir, GFS_CACHE_VNODE },
 > -	{ "shares", zfsctl_mknode_shares, GFS_CACHE_VNODE },
 >  	{ NULL }
 >  };
 
 --=20
 Pawel Jakub Dawidek                       http://www.wheelsystems.com
 pjd@FreeBSD.org                           http://www.FreeBSD.org
 FreeBSD committer                         Am I Evil? Yes, I Am!
 
 --MGYHOYXEY6WxJCY8
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.14 (FreeBSD)
 
 iEYEARECAAYFAkyPKCEACgkQForvXbEpPzSWbgCfcfu5LYdGpgx5pUH9VpgJXSrP
 gs4An2w3lTU3fUEBweLl5mrs4ILHdhig
 =tbVl
 -----END PGP SIGNATURE-----
 
 --MGYHOYXEY6WxJCY8--

From: Andriy Gapon <avg@freebsd.org>
To: jhell <jhell@DataIX.net>
Cc: Pawel Jakub Dawidek <pjd@freebsd.org>,
        "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@freebsd.org,
        mm@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 11:16:43 +0300

 on 14/09/2010 11:06 jhell said the following:
 > Andriy,
 > 	That patch-up did solve it. As for what those shares directories are
 > good for I am not sure. Do they effect the sharenfs properties at all ?.
 > If so then I know to not apply this and to just not ls(1) or cd(1) that
 > directory until a more proper fix has been applied.
 
 I don't think .zfs/shares has anything to do with sharenfs.
 I think that it is used with sharesmb, which we do not support, because we don't
 have in-kernel CIFS server.
 At least, this is what google told me :-)
 
 -- 
 Andriy Gapon

From: jhell <jhell@DataIX.net>
To: Martin Matuska <mm@freebsd.org>
Cc: Pawel Jakub Dawidek <pjd@freebsd.org>, Andriy Gapon <avg@freebsd.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 04:26:20 -0400

 On 09/14/2010 04:15, Martin Matuska wrote:
 > There was one important line missing from the merge from pjd's p4 branch.
 > 
 > Please confirm if this patch works and I will commit it ASAP.
 > 
 > Dňa 14. 9. 2010 10:06, jhell  wrote / napísal(a):
 >> On 09/14/2010 03:45, Pawel Jakub Dawidek wrote:
 >>> On Tue, Sep 14, 2010 at 10:25:36AM +0300, Andriy Gapon wrote:
 >>>> on 14/09/2010 09:35 Andriy Gapon said the following:
 >>>>>
 >>>>> Maybe this happens because we don't really support .zfs/shares, but create (or
 >>>>> try to create) that directory for some reason?
 >>>>>
 >>>>
 >>>> Could you please test this patch?
 >>
 >>> The problem was introduced AFAIK by Martin's import of v15. I think it
 >>> is handled in my v28 properly, but would need to double check. All in
 >>> all, I'd prefer if Martin could handle the problem, as I wasn't involved
 >>> in v15 and it is hard to say for me in what shape it is and what bits
 >>> are missing (Martin CCed).
 >>
 >>>> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 >>>> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 >>>> @@ -128,7 +128,6 @@ static int zfsctl_unmount_snap
 >>>>   */
 >>>>  static gfs_dirent_t zfsctl_root_entries[] = {
 >>>>  	{ "snapshot", zfsctl_mknode_snapdir, GFS_CACHE_VNODE },
 >>>> -	{ "shares", zfsctl_mknode_shares, GFS_CACHE_VNODE },
 >>>>  	{ NULL }
 >>>>  };
 >>
 >>
 >> Andriy,
 >> 	That patch-up did solve it. As for what those shares directories are
 >> good for I am not sure. Do they effect the sharenfs properties at all ?.
 >> If so then I know to not apply this and to just not ls(1) or cd(1) that
 >> directory until a more proper fix has been applied.
 >>
 >>
 >> Pawel,
 >> 	Alright future replies if I am reading into it correctly, you will be
 >> removed from CC. Thank you for listening && looking in.
 >>
 >>
 >> Regards & Thanks again,
 >>
 
 Alright patching up right now, get back to you in a moment.
 
 -- 
 
  jhell,v

From: Andriy Gapon <avg@freebsd.org>
To: Martin Matuska <mm@freebsd.org>
Cc: jhell <jhell@DataIX.net>, Pawel Jakub Dawidek <pjd@freebsd.org>,
        "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 11:34:31 +0300

 on 14/09/2010 11:15 Martin Matuska said the following:
 > There was one important line missing from the merge from pjd's p4 branch.
 > 
 > Please confirm if this patch works and I will commit it ASAP.
 
 Is this in addition to or instead of the patch I posted?
 Just clarifying.
 
 -- 
 Andriy Gapon

From: jhell <jhell@DataIX.net>
To: Martin Matuska <mm@freebsd.org>
Cc: Andriy Gapon <avg@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 04:54:58 -0400

 This is a multi-part message in MIME format.
 --------------040006010301080008000105
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 09/14/2010 04:34, Andriy Gapon wrote:
 > on 14/09/2010 11:15 Martin Matuska said the following:
 >> There was one important line missing from the merge from pjd's p4 branch.
 >>
 >> Please confirm if this patch works and I will commit it ASAP.
 > 
 > Is this in addition to or instead of the patch I posted?
 > Just clarifying.
 > 
 
 Andriy,
 I backed your patch out and applied Martin's.
 
 Martin,
 
 That patch did not work. core.txt.41 backtrace attached.
 
 - -- 
 
  jhell,v
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.16 (FreeBSD)
 
 iQEcBAEBAgAGBQJMjzhhAAoJEJBXh4mJ2FR+6ZEH/RYmVyq02PXqwozoq8L2HAq5
 LAcGVbzgR7Dgv2RCq0dQxONIOUkmID69ORWqxMAv2joUYbXkumRopW8EkYuF0Q6p
 qRnsTG8iKtUmFqFyjZngO7naQv5XNVj2dcgMQI39Hdrq7MhWzvpOWOOpuEcy4kge
 z/IS8/01LahAV3r3g2aIJL6FnkmqMtAn8pFqL/IpTXBan0ht9Oq7UNpWhWJg89Yr
 +c9YXLT3XTYYpKBalFslyFgppnLlfCcGYS28jKU7sDFjvdFiAH9E/fUWqsaH6l3O
 uZroUOKBKEuJQQDT6Itnjrwd3jnecWHQ7ztj+HZjfT4wCL3xuTZRxB9Kwob3v74=
 =Xhey
 -----END PGP SIGNATURE-----
 
 --------------040006010301080008000105
 Content-Type: text/plain;
  name="backtrace41.txt"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="backtrace41.txt"
 
 RmF0YWwgdHJhcCAxMjogcGFnZSBmYXVsdCB3aGlsZSBpbiBrZXJuZWwgbW9kZQpjcHVpZCA9
 IDA7IGFwaWMgaWQgPSAwMApmYXVsdCB2aXJ0dWFsIGFkZHJlc3MJPSAweDgwCmZhdWx0IGNv
 ZGUJCT0gc3VwZXJ2aXNvciByZWFkLCBwYWdlIG5vdCBwcmVzZW50Cmluc3RydWN0aW9uIHBv
 aW50ZXIJPSAweDIwOjB4ODA5MjIxNDUKc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgyODow
 eGI0NTE0NzJjCmZyYW1lIHBvaW50ZXIJICAgICAgICA9IDB4Mjg6MHhiNDUxNDczYwpjb2Rl
 IHNlZ21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgoJCQk9IERQ
 TCAwLCBwcmVzIDEsIGRlZjMyIDEsIGdyYW4gMQpwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJy
 dXB0IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNzCQk9IDIwMjQg
 KGxzKQp0cmFwIG51bWJlcgkJPSAxMgpwYW5pYzogcGFnZSBmYXVsdApjcHVpZCA9IDAKS0RC
 OiBzdGFjayBiYWNrdHJhY2U6CmRiX3RyYWNlX3NlbGZfd3JhcHBlcig4MDk4YmQ2NixiNDUx
 NDVjYyw4MDY2OWRhOSw4MDlhZTFhYSwwLC4uLikgYXQgMHg4MDRlMWUzOCA9IGRiX3RyYWNl
 X3NlbGZfd3JhcHBlcisweDI2CmtkYl9iYWNrdHJhY2UoODA5YWUxYWEsMCw4MDk2ZTk1OCxi
 NDUxNDVkOCwwLC4uLikgYXQgMHg4MDY5NjUyYSA9IGtkYl9iYWNrdHJhY2UrMHgyOQpwYW5p
 Yyg4MDk2ZTk1OCw4MDlhZjU4MSw4Nzg5MDhlOCwxLDEsLi4uKSBhdCAweDgwNjY5ZGE5ID0g
 cGFuaWMrMHgxMTQKdHJhcF9mYXRhbCg4NGQ2NTNhMCwwLDEsMCw4MGMxNjU2YSwuLi4pIGF0
 IDB4ODA5MGNjYTcgPSB0cmFwX2ZhdGFsKzB4MzIwCnRyYXBfcGZhdWx0KDhkM2RjNjE0LDgw
 Y2Y2MjY4LDcxYyw2ZjMsODc4OGUwMDAsLi4uKSBhdCAweDgwOTBjZWVmID0gdHJhcF9wZmF1
 bHQrMHgyM2MKdHJhcChiNDUxNDZlYykgYXQgMHg4MDkwZDdjNyA9IHRyYXArMHgzZjkKY2Fs
 bHRyYXAoKSBhdCAweDgwOGYwZjBjID0gY2FsbHRyYXArMHg2Ci0tLSB0cmFwIDB4YywgZWlw
 ID0gMHg4MDkyMjE0NSwgZXNwID0gMHhiNDUxNDcyYywgZWJwID0gMHhiNDUxNDczYyAtLS0K
 Vk9QX0xPQ0sxX0FQVig4MGQxNmVhMCxiNDUxNDc1MCxiNDUxNDc1MCw4MGExM2Y4MCw4NzRk
 NzIxOCwuLi4pIGF0IDB4ODA5MjIxNDUgPSBWT1BfTE9DSzFfQVBWKzB4M2UKX3ZuX2xvY2so
 ODc0ZDcyMTgsODA0MDAsODBjZjUzMzIsMWI1LDg3NGQ3MjE4LC4uLikgYXQgMHg4MDZmZGZi
 YyA9IF92bl9sb2NrKzB4M2QKZ2ZzX2ZpbGVfY3JlYXRlKDU0LDg2ZGUxNTNjLDg2YzhiMDAw
 LDgwZDE2ZWEwLDE4LC4uLikgYXQgMHg4MGMwOTZiNSA9IGdmc19maWxlX2NyZWF0ZSsweDY1
 Cmdmc19kaXJfY3JlYXRlKDU0LDg2ZGUxNTNjLDg2YzhiMDAwLDgwZDE2ZWEwLDAsLi4uKSBh
 dCAweDgwYzA5NzNjID0gZ2ZzX2Rpcl9jcmVhdGUrMHgyYwp6ZnNjdGxfbWtub2RlX3NoYXJl
 cyg4NmRlMTUzYyw4MGNmNTMzMiwzMDgsMzU2LDg3NGQ3MzdjLC4uLikgYXQgMHg4MGM4YTE0
 MiA9IHpmc2N0bF9ta25vZGVfc2hhcmVzKzB4NTIKZ2ZzX2Rpcl9sb29rdXAoODZkZTE1M2Ms
 YjQ1MTQ4YzAsYjQ1MTRiNzQsODgxZTRiODAsMCwuLi4pIGF0IDB4ODBjMDk1NjYgPSBnZnNf
 ZGlyX2xvb2t1cCsweDIxNgp6ZnNjdGxfcm9vdF9sb29rdXAoODZkZTE1M2MsYjQ1MTQ4YzAs
 YjQ1MTRiNzQsMCwwLC4uLikgYXQgMHg4MGM4OGFmZCA9IHpmc2N0bF9yb290X2xvb2t1cCsw
 eDEwZAp6ZnNjdGxfZnJlZWJzZF9yb290X2xvb2t1cChiNDUxNGEzNCxiNDUxNDllOCwyMDAw
 MDAsYjQ1MTRiODgsYjQ1MTRhNTQsLi4uKSBhdCAweDgwYzg5MTY2ID0gemZzY3RsX2ZyZWVi
 c2Rfcm9vdF9sb29rdXArMHhiNgpWT1BfTE9PS1VQX0FQVig4MGQwMmIwMCxiNDUxNGEzNCw4
 MDk5MDhlZiwxZjYsMCwuLi4pIGF0IDB4ODA5MjI4MDEgPSBWT1BfTE9PS1VQX0FQVisweDQ4
 Cmxvb2t1cChiNDUxNGI1Yyw4NWE0ZjgwMCw0MDAsYjQ1MTRiN2MsMCwuLi4pIGF0IDB4ODA2
 ZTU5YjQgPSBsb29rdXArMHg1ZmIKbmFtZWkoYjQ1MTRiNWMsYjQ1MTRhZmMsNjAsMCw4Nzg5
 MDc4MCwuLi4pIGF0IDB4ODA2ZTY4Y2UgPSBuYW1laSsweDU3ZAprZXJuX3N0YXRhdF92bmhv
 b2soODc4OTA3ODAsMjAwLGZmZmZmZjljLDMwNDA0M2I4LDAsLi4uKSBhdCAweDgwNmY2MjY5
 ID0ga2Vybl9zdGF0YXRfdm5ob29rKzB4NmMKa2Vybl9zdGF0YXQoODc4OTA3ODAsMjAwLGZm
 ZmZmZjljLDMwNDA0M2I4LDAsLi4uKSBhdCAweDgwNmY2M2QzID0ga2Vybl9zdGF0YXQrMHgz
 YwprZXJuX2xzdGF0KDg3ODkwNzgwLDMwNDA0M2I4LDAsYjQ1MTRjMTgsNTE4OGNlNDMsLi4u
 KSBhdCAweDgwNmY2NDBiID0ga2Vybl9sc3RhdCsweDM2CmxzdGF0KDg3ODkwNzgwLGI0NTE0
 Y2Y4LGMsYyxjLC4uLikgYXQgMHg4MDZmNjQ5ZiA9IGxzdGF0KzB4MmIKc3lzY2FsbChiNDUx
 NGQzOCkgYXQgMHg4MDkwZDFiOCA9IHN5c2NhbGwrMHgyYWIKWGludDB4ODBfc3lzY2FsbCgp
 IGF0IDB4ODA4ZjBmNzEgPSBYaW50MHg4MF9zeXNjYWxsKzB4MjEKLS0tIHN5c2NhbGwgKDE5
 MCwgRnJlZUJTRCBFTEYzMiwgbHN0YXQpLCBlaXAgPSAweDMwMWMzZjczLCBlc3AgPSAweDdm
 YmZlMmVjLCBlYnAgPSAweDdmYmZlMzc4IC0tLQpVcHRpbWU6IDJtNDJzClBoeXNpY2FsIG1l
 bW9yeTogMTAwOSBNQgpEdW1waW5nIDIxMyBNQjogMTk4IDE4MiAxNjYgMTUwIDEzNCAxMTgg
 MTAyIDg2IDcwIDU0IDM4IDIyIDYKClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5l
 bC9saW5wcm9jZnMua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbGlu
 cHJvY2ZzLmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jv
 b3Qva2VybmVsL2xpbnByb2Nmcy5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJu
 ZWwvbGludXgua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbGludXgu
 a28uc3ltYm9scy4uLmRvbmUuCmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJu
 ZWwvbGludXgua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2xpbnN5c2Zz
 LmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2xpbnN5c2ZzLmtvLnN5
 bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL2xp
 bnN5c2ZzLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC96ZnMua28uLi5k
 b25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL3pmcy5rbwpSZWFkaW5nIHN5
 bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvb3BlbnNvbGFyaXMua28uLi5kb25lLgpMb2FkZWQg
 c3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL29wZW5zb2xhcmlzLmtvClJlYWRpbmcgc3ltYm9s
 cyBmcm9tIC9ib290L2tlcm5lbC9saW5kZXYua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAv
 Ym9vdC9rZXJuZWwvbGluZGV2LmtvLnN5bWJvbHMuLi5kb25lLgpkb25lLgpMb2FkZWQgc3lt
 Ym9scyBmb3IgL2Jvb3Qva2VybmVsL2xpbmRldi5rbwpSZWFkaW5nIHN5bWJvbHMgZnJvbSAv
 Ym9vdC9rZXJuZWwvYWlvLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVs
 L2Fpby5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290
 L2tlcm5lbC9haW8ua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2NwdWZy
 ZXEua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvY3B1ZnJlcS5rby5z
 eW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9j
 cHVmcmVxLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9rc3ltcy5rby4u
 LlJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9rc3ltcy5rby5zeW1ib2xzLi4u
 ZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9rc3ltcy5rbwpS
 ZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbXF1ZXVlZnMua28uLi5SZWFkaW5n
 IHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbXF1ZXVlZnMua28uc3ltYm9scy4uLmRvbmUu
 CmRvbmUuCkxvYWRlZCBzeW1ib2xzIGZvciAvYm9vdC9rZXJuZWwvbXF1ZXVlZnMua28KIzAg
 IGRvYWR1bXAgKCkgYXQgcGNwdS5oOjIzMQoyMzEJcGNwdS5oOiBObyBzdWNoIGZpbGUgb3Ig
 ZGlyZWN0b3J5LgoJaW4gcGNwdS5oCihrZ2RiKSAjMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6
 MjMxCiMxICAweDgwNjY5YjUxIGluIGJvb3QgKGhvd3RvPTI2MCkgYXQgL3Vzci9zcmMvc3lz
 L2tlcm4va2Vybl9zaHV0ZG93bi5jOjQxNgojMiAgMHg4MDY2OWRlNSBpbiBwYW5pYyAoZm10
 PVZhcmlhYmxlICJmbXQiIGlzIG5vdCBhdmFpbGFibGUuCikgYXQgL3Vzci9zcmMvc3lzL2tl
 cm4va2Vybl9zaHV0ZG93bi5jOjU5MAojMyAgMHg4MDkwY2NhNyBpbiB0cmFwX2ZhdGFsIChm
 cmFtZT0weGI0NTE0NmVjLCBldmE9MTI4KQogICAgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4
 Ni90cmFwLmM6OTM4CiM0ICAweDgwOTBjZWVmIGluIHRyYXBfcGZhdWx0IChmcmFtZT0weGI0
 NTE0NmVjLCB1c2VybW9kZT0wLCBldmE9MTI4KQogICAgYXQgL3Vzci9zcmMvc3lzL2kzODYv
 aTM4Ni90cmFwLmM6ODUxCiM1ICAweDgwOTBkN2M3IGluIHRyYXAgKGZyYW1lPTB4YjQ1MTQ2
 ZWMpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjUzMwojNiAgMHg4MDhmMGYw
 YyBpbiBjYWxsdHJhcCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5z
 OjE2NgojNyAgMHg4MDkyMjE0NSBpbiBWT1BfTE9DSzFfQVBWICh2b3A9MHgwLCBhPTB4YjQ1
 MTQ3NTApIGF0IHZub2RlX2lmLmM6MTk4NgojOCAgMHg4MDZmZGZiYyBpbiBfdm5fbG9jayAo
 dnA9MHg4NzRkNzIxOCwgZmxhZ3M9NTI1MzEyLCAKICAgIGZpbGU9MHg4MGNmNTMzMiAiL3Vz
 ci9zcmMvc3lzL21vZHVsZXMvemZzLy4uLy4uL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy91
 dHMvY29tbW9uL2ZzL2dmcy5jIiwgbGluZT00MzcpIGF0IHZub2RlX2lmLmg6ODU5CiM5ICAw
 eDgwYzA5NmI1IGluIGdmc19maWxlX2NyZWF0ZSAoKSBmcm9tIC9ib290L2tlcm5lbC96ZnMu
 a28KIzEwIDB4ODBjMDk3M2MgaW4gZ2ZzX2Rpcl9jcmVhdGUgKCkgZnJvbSAvYm9vdC9rZXJu
 ZWwvemZzLmtvCiMxMSAweDgwYzhhMTQyIGluIHpmc2N0bF9ta25vZGVfc2hhcmVzICgpIGZy
 b20gL2Jvb3Qva2VybmVsL3pmcy5rbwojMTIgMHg4MGMwOTU2NiBpbiBnZnNfZGlyX2xvb2t1
 cCAoKSBmcm9tIC9ib290L2tlcm5lbC96ZnMua28KIzEzIDB4ODBjODhhZmQgaW4gemZzY3Rs
 X3Jvb3RfbG9va3VwICgpIGZyb20gL2Jvb3Qva2VybmVsL3pmcy5rbwojMTQgMHg4MGM4OTE2
 NiBpbiB6ZnNjdGxfZnJlZWJzZF9yb290X2xvb2t1cCAoKSBmcm9tIC9ib290L2tlcm5lbC96
 ZnMua28KIzE1IDB4ODA5MjI4MDEgaW4gVk9QX0xPT0tVUF9BUFYgKHZvcD0weDg2NjYxMDAw
 LCBhPTB4MTYpIGF0IHZub2RlX2lmLmM6MTIzCiMxNiAweDgwNmU1OWI0IGluIGxvb2t1cCAo
 bmRwPTB4YjQ1MTRiNWMpIGF0IHZub2RlX2lmLmg6NTQKIzE3IDB4ODA2ZTY4Y2UgaW4gbmFt
 ZWkgKG5kcD0weGI0NTE0YjVjKSBhdCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbG9va3VwLmM6
 MjY5CiMxOCAweDgwNmY2MjY5IGluIGtlcm5fc3RhdGF0X3ZuaG9vayAodGQ9MHg4Nzg5MDc4
 MCwgZmxhZz01MTIsIGZkPS0xMDAsIAogICAgcGF0aD0weDMwNDA0M2I4IDxBZGRyZXNzIDB4
 MzA0MDQzYjggb3V0IG9mIGJvdW5kcz4sIAogICAgcGF0aHNlZz1VSU9fVVNFUlNQQUNFLCBz
 YnA9MHhiNDUxNGMxOCwgaG9vaz0wKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N5
 c2NhbGxzLmM6MjM0NgojMTkgMHg4MDZmNjNkMyBpbiBrZXJuX3N0YXRhdCAodGQ9MHg4Nzg5
 MDc4MCwgZmxhZz01MTIsIGZkPS0xMDAsIAogICAgcGF0aD0weDMwNDA0M2I4IDxBZGRyZXNz
 IDB4MzA0MDQzYjggb3V0IG9mIGJvdW5kcz4sIAogICAgcGF0aHNlZz1VSU9fVVNFUlNQQUNF
 LCBzYnA9MHhiNDUxNGMxOCkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zeXNjYWxs
 cy5jOjIzMjcKIzIwIDB4ODA2ZjY0MGIgaW4ga2Vybl9sc3RhdCAodGQ9MHg4Nzg5MDc4MCwg
 CiAgICBwYXRoPTB4MzA0MDQzYjggPEFkZHJlc3MgMHgzMDQwNDNiOCBvdXQgb2YgYm91bmRz
 PiwgCiAgICBwYXRoc2VnPVVJT19VU0VSU1BBQ0UsIHNicD0weGI0NTE0YzE4KQogICAgYXQg
 L3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N5c2NhbGxzLmM6MjQwMAojMjEgMHg4MDZmNjQ5ZiBp
 biBsc3RhdCAodGQ9MHg4Nzg5MDc4MCwgdWFwPTB4YjQ1MTRjZjgpCiAgICBhdCAvdXNyL3Ny
 Yy9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYzoyMzkwCiMyMiAweDgwOTBkMWI4IGluIHN5c2Nh
 bGwgKGZyYW1lPTB4YjQ1MTRkMzgpCiAgICBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3Ry
 YXAuYzoxMTExCiMyMyAweDgwOGYwZjcxIGluIFhpbnQweDgwX3N5c2NhbGwgKCkKICAgIGF0
 IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MjY0CiMyNCAweDAwMDAwMDMz
 IGluID8/ICgpClByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRoaXMgZnJhbWUgKGNvcnJ1cHQg
 c3RhY2s/KQooa2dkYikgCg==
 --------------040006010301080008000105
 Content-Type: application/octet-stream;
  name="backtrace41.txt.sig"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="backtrace41.txt.sig"
 
 iQEcBAABAgAGBQJMjzhiAAoJEJBXh4mJ2FR+8eEH/3V4RGDyNpwmde7aLSjOu+9fZJuRy13T
 8Sqsf4uvvCV/+JT0FrbMeLqCuWLa6beyZIab7bz5Us9XRL13xBBiAUxeTG5Guzhz3vFqAznB
 s6IY9swbxUnPlJV3IUPOUVnrvMDurNtUamYCuJbzUJsn+COpiIKNIW/JXWZkzV42UKwDv5Qx
 qyrZAss/2RhMaeejPnd9UIcqVQUtA+SEc0NtAk4ZXw6btvcgn6pNTxNknoyAjwrfmQ+tR8Mk
 evaCi6Agb0wpTMVaPIVCQj8Bh0I3ED82egLEAUsnFIj+Vro18YOlN8+8xATRE0l95fxH1DrE
 EGjhYm4i0jEZM6ZofzYik4Y=
 --------------040006010301080008000105--

From: Andriy Gapon <avg@freebsd.org>
To: jhell <jhell@DataIX.net>
Cc: Martin Matuska <mm@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>,
        "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 12:01:13 +0300

 on 14/09/2010 11:54 jhell said the following:
 > Andriy,
 > I backed your patch out and applied Martin's.
 > 
 > Martin,
 > 
 > That patch did not work. core.txt.41 backtrace attached.
 
 It was kind of obvious (to me at least) that the Martin's patch alone won't work.
 I think I already explained what the problem is (zfsctl_mknode_shares passing
 zfsctl_ops_shares to gfs_dir_create with all vops in zfsctl_ops_shares being NULL).
 
 -- 
 Andriy Gapon

From: jhell <jhell@DataIX.net>
To: Andriy Gapon <avg@freebsd.org>
Cc: Martin Matuska <mm@freebsd.org>, 
 Pawel Jakub Dawidek <pjd@freebsd.org>,
 "Vladislav V. Prodan" <universite@ukr.net>, bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 05:16:06 -0400

 On 09/14/2010 05:01, Andriy Gapon wrote:
 > on 14/09/2010 11:54 jhell said the following:
 >> Andriy,
 >> I backed your patch out and applied Martin's.
 >>
 >> Martin,
 >>
 >> That patch did not work. core.txt.41 backtrace attached.
 > 
 > It was kind of obvious (to me at least) that the Martin's patch alone won't work.
 > I think I already explained what the problem is (zfsctl_mknode_shares passing
 > zfsctl_ops_shares to gfs_dir_create with all vops in zfsctl_ops_shares being NULL).
 > 
 
 Yeah, It didn't seem like it was really that simple for just a lock
 after I seen that message you posted before about that content/context.
 
 If that (.zfs/shares) is really not needed and we really have no way to
 use it at the moment wouldn't be useful to go through and ifdef those
 parts that effect that ?
 
 -- 
 
  jhell,v

From: Martin Matuska <mm@FreeBSD.org>
To: jhell <jhell@DataIX.net>
Cc: Andriy Gapon <avg@freebsd.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 12:10:13 +0200

 This is a multi-part message in MIME format.
 --------------020008070507050708080007
 Content-Type: text/plain; charset=windows-1250
 Content-Transfer-Encoding: 8bit
 
 This new patch should be complete for this issue, my testing succeeds.
 
 Da 14. 9. 2010 11:16, jhell  wrote / napsal(a):
 > On 09/14/2010 05:01, Andriy Gapon wrote:
 >> on 14/09/2010 11:54 jhell said the following:
 >>> Andriy,
 >>> I backed your patch out and applied Martin's.
 >>>
 >>> Martin,
 >>>
 >>> That patch did not work. core.txt.41 backtrace attached.
 >>
 >> It was kind of obvious (to me at least) that the Martin's patch alone won't work.
 >> I think I already explained what the problem is (zfsctl_mknode_shares passing
 >> zfsctl_ops_shares to gfs_dir_create with all vops in zfsctl_ops_shares being NULL).
 >>
 > 
 > Yeah, It didn't seem like it was really that simple for just a lock
 > after I seen that message you posted before about that content/context.
 > 
 > If that (.zfs/shares) is really not needed and we really have no way to
 > use it at the moment wouldn't be useful to go through and ifdef those
 > parts that effect that ?
 > 
 
 --------------020008070507050708080007
 Content-Type: text/plain;
  name="zfs_ctldir.c.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="zfs_ctldir.c.patch"
 
 Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 ===================================================================
 --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	(revision 212358)
 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	(working copy)
 @@ -1101,8 +1101,9 @@
  		return (ENOTSUP);
  	}
  	if ((error = zfs_zget(zfsvfs, zfsvfs->z_shares_dir, &dzp)) == 0) {
 +		vn_lock(ZTOV(dzp), LK_SHARED | LK_RETRY);
  		error = VOP_READDIR(ZTOV(dzp), uiop, cr, eofp, ap->a_ncookies, ap->a_cookies);
 -		VN_RELE(ZTOV(dzp));
 +		VN_URELE(ZTOV(dzp));
  	} else {
  		*eofp = 1;
  		error = ENOENT;
 @@ -1149,6 +1150,7 @@
  	    NULL, NULL);
  	sdp = vp->v_data;
  	sdp->zc_cmtime = ((zfsctl_node_t *)pvp->v_data)->zc_cmtime;
 +	VOP_UNLOCK(vp, 0);
  	return (vp);
  
  }
 @@ -1176,8 +1178,9 @@
  		return (ENOTSUP);
  	}
  	if ((error = zfs_zget(zfsvfs, zfsvfs->z_shares_dir, &dzp)) == 0) {
 +		vn_lock(ZTOV(dzp), LK_SHARED | LK_RETRY);
  		error = VOP_GETATTR(ZTOV(dzp), vap, cr);
 -		VN_RELE(ZTOV(dzp));
 +		VN_URELE(ZTOV(dzp));
  	}
  	ZFS_EXIT(zfsvfs);
  	return (error);
 @@ -1253,6 +1256,20 @@
  	.vop_fid =	zfsctl_common_fid,
  };
  
 +static struct vop_vector zfsctl_ops_shares = {
 +	.vop_default =	&default_vnodeops,
 +	.vop_open =	zfsctl_common_open,
 +	.vop_close =	zfsctl_common_close,
 +	.vop_ioctl =	VOP_EINVAL,
 +	.vop_getattr =	zfsctl_shares_getattr,
 +	.vop_access =	zfsctl_common_access,
 +	.vop_readdir =	zfsctl_shares_readdir,
 +	.vop_lookup =	zfsctl_shares_lookup,
 +	.vop_inactive =	gfs_vop_inactive,
 +	.vop_reclaim =	zfsctl_common_reclaim,
 +	.vop_fid =	zfsctl_shares_fid,
 +};
 +
  /*
   * pvp is the GFS vnode '.zfs/snapshot'.
   *
 
 --------------020008070507050708080007--

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/150544: commit references a PR
Date: Tue, 14 Sep 2010 10:27:39 +0000 (UTC)

 Author: mm
 Date: Tue Sep 14 10:27:32 2010
 New Revision: 212605
 URL: http://svn.freebsd.org/changeset/base/212605
 
 Log:
   Add missing vop_vector zfsctl_ops_shares
   Add missing locks around VOP_READDIR and VOP_GETATTR with z_shares_dir
   
   PR:		kern/150544
   Approved by:	delphij (mentor)
   Obtained from:	perforce (pjd)
   MFC after:	1 day
 
 Modified:
   head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 
 Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c
 ==============================================================================
 --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	Tue Sep 14 10:26:49 2010	(r212604)
 +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c	Tue Sep 14 10:27:32 2010	(r212605)
 @@ -1101,8 +1101,9 @@ zfsctl_shares_readdir(ap)
  		return (ENOTSUP);
  	}
  	if ((error = zfs_zget(zfsvfs, zfsvfs->z_shares_dir, &dzp)) == 0) {
 +		vn_lock(ZTOV(dzp), LK_SHARED | LK_RETRY);
  		error = VOP_READDIR(ZTOV(dzp), uiop, cr, eofp, ap->a_ncookies, ap->a_cookies);
 -		VN_RELE(ZTOV(dzp));
 +		VN_URELE(ZTOV(dzp));
  	} else {
  		*eofp = 1;
  		error = ENOENT;
 @@ -1149,6 +1150,7 @@ zfsctl_mknode_shares(vnode_t *pvp)
  	    NULL, NULL);
  	sdp = vp->v_data;
  	sdp->zc_cmtime = ((zfsctl_node_t *)pvp->v_data)->zc_cmtime;
 +	VOP_UNLOCK(vp, 0);
  	return (vp);
  
  }
 @@ -1176,8 +1178,9 @@ zfsctl_shares_getattr(ap)
  		return (ENOTSUP);
  	}
  	if ((error = zfs_zget(zfsvfs, zfsvfs->z_shares_dir, &dzp)) == 0) {
 +		vn_lock(ZTOV(dzp), LK_SHARED | LK_RETRY);
  		error = VOP_GETATTR(ZTOV(dzp), vap, cr);
 -		VN_RELE(ZTOV(dzp));
 +		VN_URELE(ZTOV(dzp));
  	}
  	ZFS_EXIT(zfsvfs);
  	return (error);
 @@ -1253,6 +1256,20 @@ static struct vop_vector zfsctl_ops_snap
  	.vop_fid =	zfsctl_common_fid,
  };
  
 +static struct vop_vector zfsctl_ops_shares = {
 +	.vop_default =	&default_vnodeops,
 +	.vop_open =	zfsctl_common_open,
 +	.vop_close =	zfsctl_common_close,
 +	.vop_ioctl =	VOP_EINVAL,
 +	.vop_getattr =	zfsctl_shares_getattr,
 +	.vop_access =	zfsctl_common_access,
 +	.vop_readdir =	zfsctl_shares_readdir,
 +	.vop_lookup =	zfsctl_shares_lookup,
 +	.vop_inactive =	gfs_vop_inactive,
 +	.vop_reclaim =	zfsctl_common_reclaim,
 +	.vop_fid =	zfsctl_shares_fid,
 +};
 +
  /*
   * pvp is the GFS vnode '.zfs/snapshot'.
   *
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
Responsible-Changed-From-To: freebsd-bugs->mm 
Responsible-Changed-By: mm 
Responsible-Changed-When: Tue Sep 14 11:02:13 UTC 2010 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=150544 

From: jhell <jhell@DataIX.net>
To: Martin Matuska <mm@freebsd.org>
Cc: Andriy Gapon <avg@freebsd.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 07:13:19 -0400

 This is a multi-part message in MIME format.
 --------------010103070604090803070706
 Content-Type: text/plain; charset=windows-1250
 Content-Transfer-Encoding: 8bit
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 09/14/2010 06:10, Martin Matuska wrote:
 > This new patch should be complete for this issue, my testing succeeds.
 > 
 > Da 14. 9. 2010 11:16, jhell  wrote / napsal(a):
 >> On 09/14/2010 05:01, Andriy Gapon wrote:
 >>> on 14/09/2010 11:54 jhell said the following:
 >>>> Andriy,
 >>>> I backed your patch out and applied Martin's.
 >>>>
 >>>> Martin,
 >>>>
 >>>> That patch did not work. core.txt.41 backtrace attached.
 >>>
 >>> It was kind of obvious (to me at least) that the Martin's patch alone won't work.
 >>> I think I already explained what the problem is (zfsctl_mknode_shares passing
 >>> zfsctl_ops_shares to gfs_dir_create with all vops in zfsctl_ops_shares being NULL).
 >>>
 >>
 >> Yeah, It didn't seem like it was really that simple for just a lock
 >> after I seen that message you posted before about that content/context.
 >>
 >> If that (.zfs/shares) is really not needed and we really have no way to
 >> use it at the moment wouldn't be useful to go through and ifdef those
 >> parts that effect that ?
 >>
 
 Solved with this patch for the cd(1) or ls(1) of snapshot or shares
 directories.
 
 Next problem probably of the same importance & same issue just different
 circumstance.
 
 Problem:
 1). ls(1) or cd(1) to snapshot or shares directory list contents "let it
 know you were there!"
 2). Drop to console, save your self some grief and ( mount -r / ) for a
 UFS root.
 3). zfs umount -a "Won't happen!" snapshot or shares will still be in use.
 4). Cannot reboot(1) & zfs umount -f -a results in panic. "Attached"
 5). Without doing 2,3,4 and using ( shutdown -r +0 ) results in the
 system getting all the way through syncing filesystems complete... and
 then hung but still have access to the kdb prompt.
 
 ??? This also happened with the first patch applied from avg@ that
 worked. ???
 
 
 Regards,
 
 - -- 
 
  jhell,v
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.16 (FreeBSD)
 
 iQEcBAEBAgAGBQJMj1jOAAoJEJBXh4mJ2FR+aOAIAIGsuybPDF7NOKpqHFx4kRBF
 nVgKrAkPw1dBg/shLBOHcenSjWKn1a2LqaWnJNXDDAkHIDV/Bb5kL3NGXWaV+c96
 xw/8jxRZl0Q/EVq5l1QpKOWi4oI2IFnswOVCHDA1G0uFaYODrzwutbuCq8MbZ4cm
 CFDRjHjNeU9wxp4kQ2Ulxr6aWkeJ3j69uHeLg1xO16xsGJfS2KLZiP/wmhEqwDjo
 TANIPXIbEX91Ts4Xn/R1muj3yV6XT6KPSIuD+rKZvV0Ep0PeN/Nnd06v4w9+av6h
 472SZaeKrVKkPrla25wceRmP4sXJ58TFnXFd8eB2xe81O6mpjxZaRrvyISIbXH4=
 =aJts
 -----END PGP SIGNATURE-----
 
 --------------010103070604090803070706
 Content-Type: text/plain;
  name="backtrace42.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="backtrace42.txt"
 
 Unread portion of the kernel message buffer:
 <118>Stopping devd.
 <118>Terminated
 <118>.
 <118>Enter full pathname of shell or RETURN for 
 <118>/bin/sh
 <118>: 
 <118># 
 <118>c
 <118>d
 <118> 
 <118>/
 <118>
 <118># 
 <118>p
 <118>w
 <118>d
 <118>
 <118>/
 <118># 
 <118>l
 <118>s
 <118> 
 <118>-
 <118>l
 <118>
 <118>total 3384
 <118>-rw-r--r--   1 root  wheel         788 May 12 03:50 .cshrc
 <118>-rw-r--r--   1 root  wheel         255 May 12 03:52 .profile
 <118>drwxrwxr-x   2 root  operator      512 Sep  7 18:23 [1m[34m.snap[39;49m[m
 <118>-r--r--r--   1 root  wheel        6198 Jul 12 14:12 COPYRIGHT
 <118>drwxr-xr-x   2 root  wheel        1024 Sep 11 22:55 [1m[34mbin[39;49m[m
 <118>drwxr-xr-x  11 root  wheel        1024 Sep 14 06:35 [1m[34mboot[39;49m[m
 <118>drwxr-xr-x   2 root  wheel         512 Sep  2 21:25 [1m[34mcdrom[39;49m[m
 <118>lrwxr-xr-x   1 root  wheel          10 Jan  3  2010 [1m[36mcompat[39;49m[m -> usr/compat
 <118>dr-xr-xr-x   7 root  wheel         512 Sep 14 02:51 [1m[34mdev[39;49m[m
 <118>drwxr-xr-x  21 root  wheel        2560 Sep 12 03:35 [1m[34metc[39;49m[m
 <118>drwxr-xr-x   6 root  wheel           9 Sep 12 09:16 [1m[34mexports[39;49m[m
 <118>drwxr-xr-x   3 root  wheel           3 Sep  6 11:15 [1m[34mhome[39;49m[m
 <118>drwxr-xr-x   3 root  wheel        1536 Sep 11 22:54 [1m[34mlib[39;49m[m
 <118>drwxr-xr-x   2 root  wheel         512 Sep  5 18:41 [1m[34mlibexec[39;49m[m
 <118>drwxr-xr-x   2 root  wheel         512 Jun 12 21:52 [1m[34mmedia[39;49m[m
 <118>drwxr-xr-x  10 root  wheel         512 Jul 30 22:58 [1m[34mmnt[39;49m[m
 <118>lrwxr-xr-x   1 root  wheel          16 Jul 21 00:23 [1m[36mnfs[39;49m[m -> mnt/nfs/disbatch
 <118>lrwxr-xr-x   1 root  wheel           9 Jan  4  2010 [1m[36mproc[39;49m[m -> root/proc
 <118>drwxr-xr-x   2 root  wheel        2560 Sep 10 15:43 [1m[34mrescue[39;49m[m
 <118>-rw-------   1 root  wheel     1653868 Sep  7 23:49 restoresymtable
 <118>drwxr-x---   9 root  wheel          26 Sep 14 04:40 [1m[34mroot[39;49m[m
 <118>drwxr-xr-x   2 root  wheel        2560 Sep  7 10:24 [1m[34msbin[39;49m[m
 <118>drwxr-xr-x   2 root  wheel         512 May 24 08:17 [1m[34mstable[39;49m[m
 <118>lrwxr-xr-x   1 root  wheel          11 Sep  5 18:40 [1m[36msys[39;49m[m -> usr/src/sys
 <118>drwxrwxrwt   6 root  wheel           6 Sep 14 06:53 [30m[42mtmp[39;49m[m
 <118>drwxr-xr-x  16 root  wheel         512 Aug 17 17:39 [1m[34musr[39;49m[m
 <118>drwxr-xr-x  27 root  wheel          27 Sep 14 02:52 [1m[34mvar[39;49m[m
 <118># 
 <118>m
 <118>u
 <118>[K
 <118>o
 <118>u
 <118>n
 <118>t
 <118>
 <118>/dev/ad0s2a on / (ufs, local)
 <118>devfs on /dev (devfs, local)
 <118>exports on /exports (zfs, local)
 <118>exports/backup on /exports/backup (zfs, local)
 <118>exports/ccache on /exports/ccache (zfs, local, nosuid)
 <118>exports/vc on /exports/vc (zfs, local, noatime)
 <118>exports/vc/cvs on /exports/vc/cvs (zfs, local, noatime)
 <118>exports/vc/cvs/ncvs on /exports/vc/cvs/ncvs (zfs, local, noatime)
 <118>exports/vc/svn on /exports/vc/svn (zfs, local, noatime)
 <118>exports/vc/svn/base on /exports/vc/svn/base (zfs, local, noatime)
 <118>exports/home on /home (zfs, local)
 <118>exports/home/u on /home/users (zfs, local)
 <118>exports/home/u/cmdlnkid on /home/users/cmdlnkid (zfs, local)
 <118>exports/home/u/jhell on /home/users/jhell (zfs, local)
 <118>exports/home/root on /root (zfs, local)
 <118>exports/tmp on /tmp (zfs, local, nosuid)
 <118>exports/compat on /usr/compat (zfs, local)
 <118>exports/doc on /usr/doc (zfs, local)
 <118>exports/local on /usr/local (zfs, local)
 <118>exports/local/etc on /usr/local/etc (zfs, local)
 <118>exports/obj on /usr/obj (zfs, local, noatime, nosuid)
 <118>exports/ports on /usr/ports (zfs, local, noatime, nosuid)
 <118>exports/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime, nosuid)
 <118>exports/src on /usr/src (zfs, local, noatime, nosuid)
 <118>exports/src/.hg on /usr/src/.hg (zfs, local, noatime, nosuid)
 <118>exports/var on /var (zfs, local)
 <118>exports/var/crash on /var/crash (zfs, local)
 <118>exports/var/db on /var/db (zfs, local)
 <118>exports/var/db/etcupdate on /var/db/etcupdate (zfs, local)
 <118>exports/var/db/pkg on /var/db/pkg (zfs, local)
 <118>exports/var/db/ports on /var/db/ports (zfs, local)
 <118>exports/var/db/portsnap on /var/db/portsnap (zfs, local)
 <118>exports/var/log on /var/log (zfs, local)
 <118>exports/var/log/archive on /var/log/archive (zfs, local)
 <118>exports/var/tmp on /var/tmp (zfs, local, nosuid)
 <118>procfs on /root/proc (procfs, local)
 <118>mqueue on /mnt/mqueue (mqueuefs, local)
 <118>linprocfs on /usr/compat/linux/proc (linprocfs, local)
 <118>linsysfs on /usr/compat/linux/sys (linsysfs, local)
 <118># 
 <118>z
 <118>f
 <118>s
 <118> 
 <118>u
 <118>m
 <118>o
 <118>u
 <118>n
 <118>t
 <118> 
 <118>-
 <118>a
 <118>
 <118>cannot unmount '/usr/obj': Device busy
 <118>cannot unmount '/usr/compat': Device busy
 <118>cannot unmount '/root': Device busy
 <118># 
 <118>m
 <118>o
 <118>u
 <118>n
 <118>t
 <118>
 <118>/dev/ad0s2a on / (ufs, local)
 <118>devfs on /dev (devfs, local)
 <118>exports/home/root on /root (zfs, local)
 <118>exports/compat on /usr/compat (zfs, local)
 <118>exports/obj on /usr/obj (zfs, local, noatime, nosuid)
 <118>procfs on /root/proc (procfs, local)
 <118>mqueue on /mnt/mqueue (mqueuefs, local)
 <118>linprocfs on /usr/compat/linux/proc (linprocfs, local)
 <118>linsysfs on /usr/compat/linux/sys (linsysfs, local)
 <118># 
 <118>mount
 <118>[3`[5@zfs u[13` -a
 <118>
 <118>a
 <118>
 <118> 
 <118>-
 <118>f
 <118>
 
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address	= 0x1a4
 fault code		= supervisor read, page not present
 instruction pointer	= 0x20:0x80659b6e
 stack pointer	        = 0x28:0xb44cead0
 frame pointer	        = 0x28:0xb44ceae8
 code segment		= base 0x0, limit 0xfffff, type 0x1b
 			= DPL 0, pres 1, def32 1, gran 1
 processor eflags	= interrupt enabled, resume, IOPL = 0
 current process		= 2670 (zfs)
 trap number		= 12
 panic: page fault
 cpuid = 0
 KDB: stack backtrace:
 db_trace_self_wrapper(8098bd66,b44ce970,80669da9,809ae1aa,0,...) at 0x804e1e38 = db_trace_self_wrapper+0x26
 kdb_backtrace(809ae1aa,0,8096e958,b44ce97c,0,...) at 0x8069652a = kdb_backtrace+0x29
 panic(8096e958,809af581,87005168,1,1,...) at 0x80669da9 = panic+0x114
 trap_fatal(8775d1d0,0,1,0,86cad440,...) at 0x8090cca7 = trap_fatal+0x320
 trap_pfault(b44cea20,80c1e2ce,86cad440,86cad3b8,8737e000,...) at 0x8090ceef = trap_pfault+0x23c
 trap(b44cea90) at 0x8090d7c7 = trap+0x3f9
 calltrap() at 0x808f0f0c = calltrap+0x6
 --- trap 0xc, eip = 0x80659b6e, esp = 0xb44cead0, ebp = 0xb44ceae8 ---
 _mtx_lock_sleep(86b8528c,87005000,0,0,0,...) at 0x80659b6e = _mtx_lock_sleep+0x3f
 vputx(b44cebe4,806f4bd7,86b85218,86d17000,80990fee,...) at 0x806f3cd0 = vputx+0x4f
 vrele(86b85218,86d17000,80990fee,964,865e3c34,...) at 0x806f45d8 = vrele+0x10
 vflush(86d17000,1,2,87005000,868b9800,...) at 0x806f4bd7 = vflush+0x5ae
 zfs_umount(86d17000,80000,b44cec40,4b4,b44cec38,...) at 0x80c9a369 = zfs_umount+0xf9
 dounmount(86d17000,80000,87005000,0,806a1bbc,...) at 0x806ebc75 = dounmount+0x4c0
 unmount(87005000,b44cecf8,c,c,c,...) at 0x806ec346 = unmount+0x3b4
 syscall(b44ced38) at 0x8090d1b8 = syscall+0x2ab
 Xint0x80_syscall() at 0x808f0f71 = Xint0x80_syscall+0x21
 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x3017ec7f, esp = 0x7fbfdc7c, ebp = 0x7fbfdca8 ---
 Uptime: 3m19s
 Physical memory: 1009 MB
 Dumping 89 MB: 74 58 42 26 10
 
 Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/linprocfs.ko
 Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/linux.ko
 Reading symbols from /boot/kernel/linsysfs.ko...Reading symbols from /boot/kernel/linsysfs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/linsysfs.ko
 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/zfs.ko
 Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/opensolaris.ko
 Reading symbols from /boot/kernel/lindev.ko...Reading symbols from /boot/kernel/lindev.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/lindev.ko
 Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/aio.ko
 Reading symbols from /boot/kernel/cpufreq.ko...Reading symbols from /boot/kernel/cpufreq.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/cpufreq.ko
 Reading symbols from /boot/kernel/ksyms.ko...Reading symbols from /boot/kernel/ksyms.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/ksyms.ko
 Reading symbols from /boot/kernel/mqueuefs.ko...Reading symbols from /boot/kernel/mqueuefs.ko.symbols...done.
 done.
 Loaded symbols for /boot/kernel/mqueuefs.ko
 #0  doadump () at pcpu.h:231
 231	pcpu.h: No such file or directory.
 	in pcpu.h
 (kgdb) #0  doadump () at pcpu.h:231
 #1  0x80669b51 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
 #2  0x80669de5 in panic (fmt=Variable "fmt" is not available.
 ) at /usr/src/sys/kern/kern_shutdown.c:590
 #3  0x8090cca7 in trap_fatal (frame=0xb44cea90, eva=420)
     at /usr/src/sys/i386/i386/trap.c:938
 #4  0x8090ceef in trap_pfault (frame=0xb44cea90, usermode=0, eva=420)
     at /usr/src/sys/i386/i386/trap.c:851
 #5  0x8090d7c7 in trap (frame=0xb44cea90) at /usr/src/sys/i386/i386/trap.c:533
 #6  0x808f0f0c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
 #7  0x80659b6e in _mtx_lock_sleep (m=0x86b8528c, tid=2264944640, opts=0, 
     file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:369
 #8  0x806f3cd0 in vputx (vp=0x86b85218, func=1)
     at /usr/src/sys/kern/vfs_subr.c:2179
 #9  0x806f45d8 in vrele (vp=0x86b85218) at /usr/src/sys/kern/vfs_subr.c:2238
 #10 0x806f4bd7 in vflush (mp=0x86d17000, rootrefs=1, flags=Variable "flags" is not available.
 )
     at /usr/src/sys/kern/vfs_subr.c:2486
 #11 0x80c9a369 in zfs_umount (vfsp=0x86d17000, fflag=524288)
     at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1477
 #12 0x806ebc75 in dounmount (mp=0x86d17000, flags=524288, td=0x87005000)
     at /usr/src/sys/kern/vfs_mount.c:1294
 #13 0x806ec346 in unmount (td=0x87005000, uap=0xb44cecf8)
     at /usr/src/sys/kern/vfs_mount.c:1179
 #14 0x8090d1b8 in syscall (frame=0xb44ced38)
     at /usr/src/sys/i386/i386/trap.c:1111
 #15 0x808f0f71 in Xint0x80_syscall ()
     at /usr/src/sys/i386/i386/exception.s:264
 #16 0x00000033 in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 (kgdb) 
 
 --------------010103070604090803070706
 Content-Type: application/octet-stream;
  name="backtrace42.txt.sig"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="backtrace42.txt.sig"
 
 iQEcBAABAgAGBQJMj1jPAAoJEJBXh4mJ2FR+ElEH/A3/xC+tPcujK0SkngkXcqydHrmACJb/
 pI7Ph0kQeBktb8gN6/7DFwm4sdjWIPCQoMGSq7NRSsJt9Eg7XI3aTotk0E4CYwT7vsdQb5rO
 XeL+q4HSIXiI3F9Hhul7qrMk9ojjmTif/2SMeV1Ie7Ojhg28JAZDEcwSEWBY4Dixyu97j1dH
 NpfZ49UdwALFTc8sjlqiKVSW53O/GZ9/m+wPeyltCuP/OAsOkb3SjJSQs/igBIDX7nM6wphc
 7vwQ5eeGuybKH69SVgSTa9OtC96ATo2fFApsiNwE0ylpE0nOh8dWuZlDWTXfa7SlCjQaD/6m
 lyrpZJSqtZ/KTRxYhu34WyM=
 --------------010103070604090803070706--

From: Martin Matuska <mm@FreeBSD.org>
To: jhell <jhell@DataIX.net>
Cc: Andriy Gapon <avg@freebsd.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 13:30:22 +0200

 There is a much easier way to reproduce the second problem:
 
 a) mount a ZFS filesystem and have at least one snapshot (e.g. tank/test
 on /test)
 b) list the contents of the snapshot (makes an auto-mount, e.g. list
 /test/.zfs/snapshot/snap1)
 c) umount the dataset (zfs umount tank/snap)
 - gives error ("dataset busy")
 d) umount it again (zfs umount tank/snap)
 - panic
 
 I will have more time to investigate this tomorrow.

From: Martin Matuska <mm@FreeBSD.org>
To: jhell <jhell@DataIX.net>
Cc: Andriy Gapon <avg@freebsd.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 14:09:43 +0200

 This is a multi-part message in MIME format.
 --------------030402040505070105010108
 Content-Type: text/plain; charset=windows-1250
 Content-Transfer-Encoding: 8bit
 
 The second problem was due to a v15 mismerge (duplicate code) in
 zfs_vfsops.c, should be fixed by this patch.
 
 Da 14. 9. 2010 13:13, jhell  wrote / napsal(a):
 > On 09/14/2010 06:10, Martin Matuska wrote:
 >> This new patch should be complete for this issue, my testing succeeds.
 > 
 >> DHa 14. 9. 2010 11:16, jhell  wrote / napsal(a):
 >>> On 09/14/2010 05:01, Andriy Gapon wrote:
 >>>> on 14/09/2010 11:54 jhell said the following:
 >>>>> Andriy,
 >>>>> I backed your patch out and applied Martin's.
 >>>>>
 >>>>> Martin,
 >>>>>
 >>>>> That patch did not work. core.txt.41 backtrace attached.
 >>>>
 >>>> It was kind of obvious (to me at least) that the Martin's patch alone won't work.
 >>>> I think I already explained what the problem is (zfsctl_mknode_shares passing
 >>>> zfsctl_ops_shares to gfs_dir_create with all vops in zfsctl_ops_shares being NULL).
 >>>>
 >>>
 >>> Yeah, It didn't seem like it was really that simple for just a lock
 >>> after I seen that message you posted before about that content/context.
 >>>
 >>> If that (.zfs/shares) is really not needed and we really have no way to
 >>> use it at the moment wouldn't be useful to go through and ifdef those
 >>> parts that effect that ?
 >>>
 > 
 > Solved with this patch for the cd(1) or ls(1) of snapshot or shares
 > directories.
 > 
 > Next problem probably of the same importance & same issue just different
 > circumstance.
 > 
 > Problem:
 > 1). ls(1) or cd(1) to snapshot or shares directory list contents "let it
 > know you were there!"
 > 2). Drop to console, save your self some grief and ( mount -r / ) for a
 > UFS root.
 > 3). zfs umount -a "Won't happen!" snapshot or shares will still be in use.
 > 4). Cannot reboot(1) & zfs umount -f -a results in panic. "Attached"
 > 5). Without doing 2,3,4 and using ( shutdown -r +0 ) results in the
 > system getting all the way through syncing filesystems complete... and
 > then hung but still have access to the kdb prompt.
 > 
 > ??? This also happened with the first patch applied from avg@ that
 > worked. ???
 > 
 > 
 > Regards,
 > 
 
 --------------030402040505070105010108
 Content-Type: text/plain;
  name="zfs_vfsops.c.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="zfs_vfsops.c.patch"
 
 Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
 ===================================================================
 --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c	(revision 212605)
 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c	(working copy)
 @@ -1226,13 +1226,6 @@
  	if (error == 0 && ((zfsvfs_t *)vfsp->vfs_data)->z_issnap)
  		VFS_HOLD(mvp->v_vfsp);
  
 -	/*
 -	 * Add an extra VFS_HOLD on our parent vfs so that it can't
 -	 * disappear due to a forced unmount.
 -	 */
 -	if (error == 0 && ((zfsvfs_t *)vfsp->vfs_data)->z_issnap)
 -		VFS_HOLD(mvp->v_vfsp);
 -
  out:
  	return (error);
  }
 
 --------------030402040505070105010108--

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/150544: commit references a PR
Date: Tue, 14 Sep 2010 12:12:22 +0000 (UTC)

 Author: mm
 Date: Tue Sep 14 12:12:18 2010
 New Revision: 212611
 URL: http://svn.freebsd.org/changeset/base/212611
 
 Log:
   Remove duplicated VFS_HOLD due to a mismerge.
   
   PR:		kern/150544
   Approved by:	delphij (mentor)
   MFC after:	1 day
 
 Modified:
   head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
 
 Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
 ==============================================================================
 --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c	Tue Sep 14 12:12:07 2010	(r212610)
 +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c	Tue Sep 14 12:12:18 2010	(r212611)
 @@ -1226,13 +1226,6 @@ zfs_mount(vfs_t *vfsp)
  	if (error == 0 && ((zfsvfs_t *)vfsp->vfs_data)->z_issnap)
  		VFS_HOLD(mvp->v_vfsp);
  
 -	/*
 -	 * Add an extra VFS_HOLD on our parent vfs so that it can't
 -	 * disappear due to a forced unmount.
 -	 */
 -	if (error == 0 && ((zfsvfs_t *)vfsp->vfs_data)->z_issnap)
 -		VFS_HOLD(mvp->v_vfsp);
 -
  out:
  	return (error);
  }
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->patched 
State-Changed-By: arundel 
State-Changed-When: Tue Sep 14 12:26:16 UTC 2010 
State-Changed-Why:  
Patched in HEAD (r212605, r212611). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=150544 

From: jhell <jhell@DataIX.net>
To: Martin Matuska <mm@freebsd.org>
Cc: Andriy Gapon <avg@freebsd.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@freebsd.org
Subject: Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 08:21:46 -0400

 On 09/14/2010 08:09, Martin Matuska wrote:
 > The second problem was due to a v15 mismerge (duplicate code) in
 > zfs_vfsops.c, should be fixed by this patch.
 > 
 > Da 14. 9. 2010 13:13, jhell  wrote / napsal(a):
 >> On 09/14/2010 06:10, Martin Matuska wrote:
 >>> This new patch should be complete for this issue, my testing succeeds.
 >>
 >>> DHa 14. 9. 2010 11:16, jhell  wrote / napsal(a):
 >>>> On 09/14/2010 05:01, Andriy Gapon wrote:
 >>>>> on 14/09/2010 11:54 jhell said the following:
 >>>>>> Andriy,
 >>>>>> I backed your patch out and applied Martin's.
 >>>>>>
 >>>>>> Martin,
 >>>>>>
 >>>>>> That patch did not work. core.txt.41 backtrace attached.
 >>>>>
 >>>>> It was kind of obvious (to me at least) that the Martin's patch alone won't work.
 >>>>> I think I already explained what the problem is (zfsctl_mknode_shares passing
 >>>>> zfsctl_ops_shares to gfs_dir_create with all vops in zfsctl_ops_shares being NULL).
 >>>>>
 >>>>
 >>>> Yeah, It didn't seem like it was really that simple for just a lock
 >>>> after I seen that message you posted before about that content/context.
 >>>>
 >>>> If that (.zfs/shares) is really not needed and we really have no way to
 >>>> use it at the moment wouldn't be useful to go through and ifdef those
 >>>> parts that effect that ?
 >>>>
 >>
 >> Solved with this patch for the cd(1) or ls(1) of snapshot or shares
 >> directories.
 >>
 >> Next problem probably of the same importance & same issue just different
 >> circumstance.
 >>
 >> Problem:
 >> 1). ls(1) or cd(1) to snapshot or shares directory list contents "let it
 >> know you were there!"
 >> 2). Drop to console, save your self some grief and ( mount -r / ) for a
 >> UFS root.
 >> 3). zfs umount -a "Won't happen!" snapshot or shares will still be in use.
 >> 4). Cannot reboot(1) & zfs umount -f -a results in panic. "Attached"
 >> 5). Without doing 2,3,4 and using ( shutdown -r +0 ) results in the
 >> system getting all the way through syncing filesystems complete... and
 >> then hung but still have access to the kdb prompt.
 >>
 >> ??? This also happened with the first patch applied from avg@ that
 >> worked. ???
 >>
 >>
 >> Regards,
 >>
 
 Dude! how many of those are supposed to be there! ;)
 
 -- 
 
  jhell,v

From: jhell <jhell@DataIX.net>
To: Martin Matuska <mm@freebsd.org>
Cc: Andriy Gapon <avg@freebsd.org>, 
 "Vladislav V. Prodan" <universite@ukr.net>,
 bug-followup@freebsd.org
Subject: [SOLVED] Re: kern/150544: Panic, when viewing the list of ZFS snapshots
Date: Tue, 14 Sep 2010 08:37:31 -0400

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 09/14/2010 08:09, Martin Matuska wrote:
 > The second problem was due to a v15 mismerge (duplicate code) in
 > zfs_vfsops.c, should be fixed by this patch.
 
 I concur. The last two patches from you solves both of those problems on
 stable/8 i386 and will most likely do the same on HEAD.
 
 
 Thank you all a lot! for you help,
 
 Regards,
 
 - -- 
 
  jhell,v
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.16 (FreeBSD)
 
 iQEcBAEBAgAGBQJMj2yLAAoJEJBXh4mJ2FR+KFYH/0Dphc+JvdLJOcDk3FywP/Yt
 4WWuRhyfMf8t6tvNfBcJRuJEvLVrLgxR/OT/yhYevIR/ZiRpU63u7mDxwpQi9IM7
 weE//165laZbWbVLDeCJshDmw4Smll4qhHHfT4Qz4PtQjSCWma4X94i57GGWbhM+
 i/jABB5wIeEwuPvfT7oS6P0+Tno3VzVdSd+NwrlZxrMkaExBY+/tRBtoRcgHY48F
 FBbxBwRMbJfa/ecyu1ZM9+11SfnKZlCnnvl6qoezDXIqex0lC8hThCaHfwBayuln
 TJwzimSpeMB9az4XdWqiI3IKVr9jWdlGB6eUY1CARVu+mD8yQVk3jfAYBvH9di8=
 =ylMW
 -----END PGP SIGNATURE-----
State-Changed-From-To: patched->closed 
State-Changed-By: mm 
State-Changed-When: Wed Sep 15 16:52:16 UTC 2010 
State-Changed-Why:  
Resolved. Thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=150544 
>Unformatted:
