• Satya Tangirala's avatar
    fs: Fix freeze_bdev()/thaw_bdev() accounting of bd_fsfreeze_sb · 04a6a536
    Satya Tangirala authored
    freeze/thaw_bdev() currently use bdev->bd_fsfreeze_count to infer
    whether or not bdev->bd_fsfreeze_sb is valid (it's valid iff
    bd_fsfreeze_count is non-zero). thaw_bdev() doesn't nullify
    bd_fsfreeze_sb.
    
    But this means a freeze_bdev() call followed by a thaw_bdev() call can
    leave bd_fsfreeze_sb with a non-null value, while bd_fsfreeze_count is
    zero. If freeze_bdev() is called again, and this time
    get_active_super() returns NULL (e.g. because the FS is unmounted),
    we'll end up with bd_fsfreeze_count > 0, but bd_fsfreeze_sb is
    *untouched* - it stays the same (now garbage) value. A subsequent
    thaw_bdev() will decide that the bd_fsfreeze_sb value is legitimate
    (since bd_fsfreeze_count > 0), and attempt to use it.
    
    Fix this by always setting bd_fsfreeze_sb to NULL when
    bd_fsfreeze_count is successfully decremented to 0 in thaw_sb().
    Alternatively, we could set bd_fsfreeze_sb to whatever
    get_active_super() returns in freeze_bdev() whenever bd_fsfreeze_count
    is successfully incremented to 1 from 0 (which can be achieved cleanly
    by moving the line currently setting bd_fsfreeze_sb to immediately
    after the "sync:" label, but it might be a little too subtle/easily
    overlooked in future).
    
    This fixes the currently panicking xfstests generic/085.
    
    Fixes: 040f04bd ("fs: simplify freeze_bdev/thaw_bdev")
    Signed-off-by: default avatarSatya Tangirala <satyat@google.com>
    Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    04a6a536
block_dev.c 47.9 KB