aboutsummaryrefslogtreecommitdiffstats
path: root/fs/proc/array.c
diff options
context:
space:
mode:
authorJosef Bacik <[email protected]>2009-11-11 20:53:34 +0000
committerChris Mason <[email protected]>2009-11-11 20:53:34 +0000
commita6dbd429d8dd3382bbd9594b8d2ec74843a260d9 (patch)
tree9cc6426da748996e4e1cc61d446052838703434f /fs/proc/array.c
parentBtrfs: allow more metadata chunk preallocation (diff)
downloadkernel-a6dbd429d8dd3382bbd9594b8d2ec74843a260d9.tar.gz
kernel-a6dbd429d8dd3382bbd9594b8d2ec74843a260d9.zip
Btrfs: fix panic when trying to destroy a newly allocated
There is a problem where iget5_locked will look for an inode, not find it, and then subsequently try to allocate it. Another CPU will have raced in and allocated the inode instead, so when iget5_locked gets the inode spin lock again and does a search, it finds the new inode. So it goes ahead and calls destroy_inode on the inode it just allocated. The problem is we don't set BTRFS_I(inode)->root until the new inode is completely initialized. This patch makes us set root to NULL when alloc'ing a new inode, so when we get to btrfs_destroy_inode and we see that root is NULL we can just free up the memory and continue on. This fixes the panic http://www.kerneloops.org/submitresult.php?number=812690 Thanks, Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Chris Mason <[email protected]>
Diffstat (limited to 'fs/proc/array.c')
0 files changed, 0 insertions, 0 deletions