On Tue, May 14, 2019 at 01:54:37PM +0300, Nikolay Borisov wrote: > While fixing the failing ASSERT in device replace finishing procedure I also > found several oddities/bugs. Here is the resultant pile. > > First 3 patches are a couple simple cleanups. > > Patch 4 fixes a real bug since btrfs_init_dev_replace_tgtdev accesses values > which might be updated by transaction commit, so naturally it should be called > after the transaction is actually committed. I think this should go to > stable. > > Patch 5 cleanups unlocking code in btrfs_dev_replace_start removing a goto > label > and a local variable. > > Patch 6 also fixes a bug, since persisting the dev-replace item relied on > global > reserve being able to satisfy the condition. While this is not wrong per-se I > find it somewhat subtle, so just be explicit and start a transaction with > reservation for at least 1 item. > > Patch 7 fixes the race condition which caused the newly added ASSERT to > trigger. > I've added the Fixes: tag to point to the first commit which introduced > taking > chunk_mutex. This is also stable material. > > Patch 8 is also a minor cleanup, just removing what I believe to be a > redundant > assignment. > > This series went under multiple xfstest runs and no regressions were > observed. > > Nikolay Borisov (8): > btrfs: Don't opencode sync_blockdev in btrfs_init_dev_replace_tgtdev > btrfs: Reduce critical section in btrfs_init_dev_replace_tgtdev > btrfs: Remove impossible WARN_ON > btrfs: Ensure btrfs_init_dev_replace_tgtdev sees up to date values > btrfs: Streamline replace sem unlock in btrfs_dev_replace_start > btrfs: Explicitly reserve space for devreplace item > btrfs: Ensure replaced device doesn't have pending chunk allocation > btrfs: Remove redundant assignment of tgt_device->commit_total_bytes
Added as topic branch and to for-next will be moved to misc-next soon.
