This has been resolved before the release.

:>     Ok, let me fix this one, I have a patch set from the other work almost
:>     ready to go and I'll just add the appropriate code for the cross link
:>     check.
:
:Sure, I can try patches anytime.
:
:Thanks.

    Ok, its all committed.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

Hehe, I wasn't quick enough to work on a fix for PFS.

Sure, I can try patches anytime.

Thanks.

Bleh.  I just thought of another problem.  The kernel has no clue
    about PFS's.  I guess we have to do the cross-device link check in
    HAMMER anyway, so it can also check for attempts to link across PFS
    boundaries.

    Ok, let me fix this one, I have a patch set from the other work almost
    ready to go and I'll just add the appropriate code for the cross link
    check.

						-Matt

:A-ha, looking at ktrace output (somehow truss stuck in the middle of
:execution) and the UFS source code, HAMMER lacks cross-device link checks
:in nlink and nrename.  I'll work on a patch for this one.
:
:Cheers.

    Ah, ok, you can abort that core dump download then.

    The DragonFly kernel is supposed to do that check.  At least, I 
    assumed that the DragonFly kernel would do that check, so I didn't
    do it in HAMMER.  I will fix the kernel.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:A-ha, looking at ktrace output (somehow truss stuck in the middle of
:execution) and the UFS source code, HAMMER lacks cross-device link checks
:in nlink and nrename.  I'll work on a patch for this one.
:
:Cheers.

    Oh, sorry, as usual I didn't completely read your short posting :-)

    If you would like to fix it, please go ahead!  Please fix it in
    the upper layers of the kernel though, not in HAMMER.  The kernel
    is supposed to vet cross device link checks before diving into the VOP.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

A-ha, looking at ktrace output (somehow truss stuck in the middle of
execution) and the UFS source code, HAMMER lacks cross-device link checks
in nlink and nrename.  I'll work on a patch for this one.

Cheers.

Hi.
Running git-clone to a HAMMER filesystem instantly triggers a kernel panic
while just cpdup'ing the repository to a HAMMER filesystem doesn't.  Both
kernel and the world is freshly built from the latest 2.0 source.  I also
ran newfs_hammer to make sure I don't have stale filesystem.  I can reproduce
the panic without running cpdup prior to git-clone.  The git repo to be
cloned doen't need to be large, just a single change set is enough, but
it often locks up during the kernel dumping.  I'm transfering the vmcore
to leaf right now, but it seems to take more than an hour.

(create a small git repo)
# cd
# mkdir test && cd test && git init
# echo TEST > TEST
# git add TEST
# git commit -m TEST

# cd /HAMMER
# cpdup /where/I/keep/git/pkgsrc cpdupped (no crash)
# sync; sync; sync
# git-clone --bare ~/test git (panic)

Fatal trap 12: page fault while in kernel mode
mp_lock = 00000000; cpuid = 0; lapic.id = 00000000
fault virtual address   = 0x98
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0256ca9
stack pointer           = 0x10:0xd5eb79e8
frame pointer           = 0x10:0xd5eb79e8
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         = 1047 (git)
current thread          = pri 6
 <- SMP: XXX
trap number             = 12
panic: page fault
mp_lock = 00000000; cpuid = 0
boot() called on cpu#0

(kgdb) bt
#0  dumpsys () at ./machine/thread.h:83
#1  0xc0198cbd in boot (howto=256)
    at /home/source/dragonfly/R2_0/src/sys/kern/kern_shutdown.c:375
#2  0xc0198f80 in panic (fmt=0xc02d8f68 "%s")
    at /home/source/dragonfly/R2_0/src/sys/kern/kern_shutdown.c:800
#3  0xc02b13a2 in trap_fatal (frame=0xd5eb79a0, eva=<value optimized out>)
    at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/trap.c:1138
#4  0xc02b14dc in trap_pfault (frame=0xd5eb79a0, usermode=0, eva=152)
    at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/trap.c:1039
#5  0xc02b1b0c in trap (frame=0xd5eb79a0)
    at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/trap.c:719
#6  0xc029e9c7 in calltrap ()
    at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/exception.s:785
#7  0xc0256ca9 in hammer_modify_inode (ip=0xd5e05500, flags=1)
    at /home/source/dragonfly/R2_0/src/sys/vfs/hammer/hammer_inode.c:1342
#8  0xc025e448 in hammer_ip_add_directory (trans=0xd5eb7af0, dip=0xd2981250,
    name=0xc25091c0 "02d41ce21323b1cdc228c78cec2f81c054bd34", bytes=38,
    ip=0xd5e05500)
    at /home/source/dragonfly/R2_0/src/sys/vfs/hammer/hammer_object.c:630
#9  0xc0267dab in hammer_vop_nlink (ap=0xd5eb7b2c)
    at /home/source/dragonfly/R2_0/src/sys/vfs/hammer/hammer_vnops.c:1010
#10 0xc01ecdfd in vop_nlink (ops=0xcc3b0170, nch=0xd5eb7c48, dvp=0xd5e223e8,
    vp=0xd5e3ec28, cred=0xd5bd2c18)
    at /home/source/dragonfly/R2_0/src/sys/kern/vfs_vopops.c:1091
#11 0xc01e84b1 in kern_link (nd=0xd5eb7c80, linknd=0xd5eb7c48)
    at /home/source/dragonfly/R2_0/src/sys/kern/vfs_syscalls.c:2080
#12 0xc01e851c in sys_link (uap=0xd5eb7cf0)
    at /home/source/dragonfly/R2_0/src/sys/kern/vfs_syscalls.c:2102
#13 0xc02b223f in syscall2 (frame=0xd5eb7d40)
    at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/trap.c:1384
#14 0xc029ea76 in Xint0x80_syscall ()
    at /home/source/dragonfly/R2_0/src/sys/platform/pc32/i386/exception.s:876
#15 0x282e6324 in ?? ()

Cheers.