diff options
author | Josef Bacik <josef@redhat.com> | 2009-11-11 15:53:34 -0500 |
---|---|---|
committer | Chris Mason <chris.mason@oracle.com> | 2009-11-11 15:53:34 -0500 |
commit | a6dbd429d8dd3382bbd9594b8d2ec74843a260d9 (patch) | |
tree | 9cc6426da748996e4e1cc61d446052838703434f /mm | |
parent | 33b258086441dd07e00133c79fcd8cbc6a76d737 (diff) | |
download | linux-stable-a6dbd429d8dd3382bbd9594b8d2ec74843a260d9.tar.gz linux-stable-a6dbd429d8dd3382bbd9594b8d2ec74843a260d9.tar.bz2 linux-stable-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 <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions