Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PANIC at zfs_dir.c:784:zfs_link_create() #3222

Closed
nedbass opened this issue Mar 24, 2015 · 1 comment
Closed

PANIC at zfs_dir.c:784:zfs_link_create() #3222

nedbass opened this issue Mar 24, 2015 · 1 comment
Milestone

Comments

@nedbass
Copy link
Contributor

nedbass commented Mar 24, 2015

Probably related to #3195. The filesystem has xattr=sa set.

ZFS: Loaded module v0.6.3-246_g8120888 (DEBUG mode), ZFS pool version 5000, ZFS filesystem version 5
 vda: vda1 vda9
SPL: using hostid 0x00000000
VERIFY(error == 0) failed
PANIC at zfs_dir.c:784:zfs_link_create()
Showing stack for process 6836
Pid: 6836, comm: mktemp Not tainted 2.6.32-431.23.3.1chaos.ch5.2.x86_64 #1
Call Trace:
 [<ffffffffa03ce8ad>] ? spl_dumpstack+0x3d/0x40 [spl]
 [<ffffffffa03ceaa2>] ? spl_panic+0xc2/0xe0 [spl]
 [<ffffffff81000a64>] ? _stext+0x8cc/0xe68
 [<ffffffff8100add6>] ? ftrace_call+0x5/0x2b
 [<ffffffff8152c309>] ? _cond_resched+0x9/0x40
 [<ffffffffa04ccebb>] ? dbuf_rele+0x6b/0xb0 [zfs]
 [<ffffffffa04ce40e>] ? dmu_buf_rele+0xe/0x10 [zfs]
 [<ffffffffa057b870>] ? zap_unlockdir+0xf0/0x190 [zfs]
 [<ffffffffa057ccc3>] ? zap_add+0xf3/0x1f0 [zfs]
 [<ffffffffa0589860>] ? zfs_link_create+0x680/0x720 [zfs]
 [<ffffffff8152cc89>] ? mutex_unlock+0x9/0x20
 [<ffffffffa05ac0f0>] ? zfs_create+0x670/0x8d0 [zfs]
 [<ffffffffa05d139c>] ? zpl_create+0x9c/0x1d0 [zfs]
 [<ffffffff810f1516>] ? ftrace_test_stop_func+0x16/0x20
 [<ffffffff8100add6>] ? ftrace_call+0x5/0x2b
 [<ffffffff81199586>] ? vfs_create+0xe6/0x110
 [<ffffffff8119d5ce>] ? do_filp_open+0xa8e/0xd20
 [<ffffffff811a98c1>] ? expand_files+0x21/0x220
 [<ffffffff811a9b52>] ? alloc_fd+0x92/0x160
 [<ffffffff81186c89>] ? do_sys_open+0x69/0x140
 [<ffffffff8100add6>] ? ftrace_call+0x5/0x2b
 [<ffffffff81186da0>] ? sys_open+0x20/0x30
 [<ffffffff8100b0b2>] ? system_call_fastpath+0x16/0x1b

Was using this stress test that writes random xattr to the directory while creating, removing, and writing data to files.

#!/bin/bash

DIR=$1
MAX_WRITE_SIZE=131072
DIR_LEN=`echo -n $DIR | wc -c`
MAX_FILENAME_LEN=$(( 255 - $DIR_LEN ))

if [ -z "$DIR" ] ; then
        echo "Usage: $0 <zfs directory>"
        exit  1
fi

shopt -s nullglob

randsleep()
{
        local MAXSLEEP=${1:-'30'}
        sleep $(( $RANDOM % $MAXSLEEP ))
}

randbase64()
{
        local MAXBYTES=${1:-'4096'}
        dd if=/dev/urandom bs=1 count=$(( $RANDOM % $MAXBYTES )) 2>/dev/null |
                openssl enc -a -A
}

coinflip()
{
        if [ 50 -gt $(( $RANDOM % 100 )) ] ; then
                return 0
        else
                return 1
        fi
}

killjobs()
{
        jobs -p | xargs kill
}

# Create randomly named files.
while :; do
        for ((i=0; i< $(( $RANDOM % 256 )); i++)) ; do
                len=$(( 3 + $(( $RANDOM % $(( MAX_FILENAME_LEN - 3 ))))))
                template=`perl -e 'print "X" x $ARGV[0]' $len`
                mktemp /tank/fish/$template > /dev/null
        done
        randsleep
done &

# Write some data to each file.
while :; do
        randsleep
        for f in $DIR/* ; do
                dd oflag=nofollow if=/dev/urandom of="$f" bs=512 \
                        count=$(( $RANDOM % $(( MAX_WRITE_SIZE / 512)))) \
                        2>/dev/null
        done
done &

# Randomly remove files.
while :; do
        randsleep
        for f in $DIR/* ; do
                if coinflip ; then
                        rm "$f" 2>/dev/null
                fi
        done
done &

# Write random xattr values to the directory or remove them.
while :; do
        sleep .5
        if coinflip ; then
                v=`randbase64`
                setfattr -h -n trusted.foo -v 0s$v $DIR 2>/dev/null
        else
                setfattr -h -x trusted.foo $DIR 2>/dev/null
        fi
done &

trap killjobs SIGINT

if [ -n "$2" ] ; then
        sleep $2
        killjobs
else
        wait
fi
@nedbass
Copy link
Contributor Author

nedbass commented Mar 24, 2015

Code snippet for the ASSERT.

        error = zap_add(ZTOZSB(zp)->z_os, dzp->z_id, dl->dl_name,
            8, 1, &value, tx); 
        ASSERT(error == 0);

nedbass added a commit to nedbass/zfs that referenced this issue Mar 25, 2015
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3222
nedbass added a commit to nedbass/zfs that referenced this issue Mar 25, 2015
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3204
Fixes openzfs#3222
nedbass added a commit to nedbass/zfs that referenced this issue Mar 25, 2015
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3204
Fixes openzfs#3222
@behlendorf behlendorf added this to the 0.6.4 milestone Mar 25, 2015
DeHackEd pushed a commit to DeHackEd/zfs that referenced this issue Apr 4, 2015
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3204
Fixes openzfs#3222
DeHackEd pushed a commit to DeHackEd/zfs that referenced this issue Apr 5, 2015
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3204
Fixes openzfs#3222
behlendorf pushed a commit to behlendorf/zfs that referenced this issue Jun 9, 2015
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3222
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants