git: hammer2 - Correct allocator race and related corruption
dillon at crater.dragonflybsd.org
Thu Apr 11 20:08:24 PDT 2019
Author: Matthew Dillon <dillon at apollo.backplane.com>
Date: Thu Apr 11 19:04:56 2019 -0700
hammer2 - Correct allocator race and related corruption
* When allocating fragments (below 16KB), for example 1K directory
entries, 1K inodes, compressed file blocks that happen to be
fragments, or end-of-file fragments, the allocator must ensure
that any partially freed block is set back to fully allocated.
* In this specific case the allocator was not setting the
correct bits in the freemap. The situation never occurs
on a block boundary (different code is executed which does
the correct calculation), so the related block will always
be in a minimally allocated state (either partially allocated
or fully allocated).
This means that the corruption can only happen under the specific
circumstance where a fragment is allocated out of a block that
the bulkfree code is simultaneously trying to free (marking it
partially-allocated). Because the wrong bits are set, the NEXT
bulkfree pass can also miss the fact that the fragment is
allocated and finish transitioning the block from partially-
allocated to fully-free.
A later allocation then corrupts the block, resulting in CHECK
errors on the console.
* Because the bulkfree code always comes in and in ALL SITUATIONS OTHER
THAN THIS SPECIFIC RACE will re-mark the blocks fully-allocated,
the corruption can ONLY occur during heavy write activity during
a bulkfree operation, typically when heavy manipulation of directory
entries or inodes occurs.
* Correct the fragmentary bitmap calculation to set the proper
Summary of changes:
sys/vfs/hammer2/hammer2_bulkfree.c | 36 +++++++++++++++++++++---------------
sys/vfs/hammer2/hammer2_freemap.c | 11 +++++++++--
2 files changed, 30 insertions(+), 17 deletions(-)
DragonFly BSD source repository
More information about the Commits