Zach Brown 44588c1d8b Lock btree merges ...

The btree locking wasn't covering the merge candidate block before the
siblings were locked.  In that unlocked code it could compact the block
corrupting it for whatever other tree walk might only have the merge
candidate locked after having unlocked the parent.

This extends locking coverage to merge and split attempts by acquiring
the block lock immediately after we read it.  Split doesn't have to lock
its destination block but it does have to know to unlock the block on
errors.  Merge has to more carefully lock both of its existing blocks in
a consistent order.

To clearly implement this we simplify the locking helpers to just unlock
and lock a given block, falling back to the btree rwsem if there isn't a
block.

I started down this road while chasing allocator bugs that manifested as
tree corruption.

Signed-off-by: Zach Brown <zab@versity.com>

2016-11-08 16:05:37 -08:00

kmod

Lock btree merges

2016-11-08 16:05:37 -08:00

S

Description

No description provided

7.5 MiB

Languages

C 86.4%

Shell 9.9%

Roff 2.5%

TeX 0.8%

Makefile 0.4%