]> git.baikalelectronics.ru Git - kernel.git/commit
Btrfs: fix deadlock caused by the nested chunk allocation
authorMiao Xie <miaox@cn.fujitsu.com>
Tue, 16 Oct 2012 11:26:46 +0000 (11:26 +0000)
committerChris Mason <chris.mason@fusionio.com>
Thu, 25 Oct 2012 19:47:00 +0000 (15:47 -0400)
commiteb682794db43d7581493fc60b7321e9692f5f5cc
tree77ec90c39aa7fa567f2232e18a8c3440c16fd294
parentadd3b7532229e15cf6f4d82b8876d2931c11ba8c
Btrfs: fix deadlock caused by the nested chunk allocation

Steps to reproduce:
 # mkfs.btrfs -m raid1 <disk1> <disk2>
 # btrfstune -S 1 <disk1>
 # mount <disk1> <mnt>
 # btrfs device add <disk3> <disk4> <mnt>
 # mount -o remount,rw <mnt>
 # dd if=/dev/zero of=<mnt>/tmpfile bs=1M count=1
 Deadlock happened.

It is because of the nested chunk allocation. When we wrote the data
into the filesystem, we would allocate the data chunk because there was
no data chunk in the filesystem. At the end of the data chunk allocation,
we should insert the metadata of the data chunk into the extent tree, but
there was no raid1 chunk, so we tried to lock the chunk allocation mutex to
allocate the new chunk, but we had held the mutex, the deadlock happened.

By rights, we would allocate the raid1 chunk when we added the second device
because the profile of the seed filesystem is raid1 and we had two devices.
But we didn't do that in fact. It is because the last step of the first device
insertion didn't commit the transaction. So when we added the second device,
we didn't cow the tree, and just inserted the relative metadata into the leaves
which were generated by the first device insertion, and its profile was dup.

So, I fix this problem by commiting the transaction at the end of the first
device insertion.

Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
fs/btrfs/volumes.c