kernel/fs/btrfs/dev-replace.c, branch linux-5.1.y

btrfs: Ensure replaced device doesn't have pending chunk allocation

2019-07-10T07:52:31Z

commit debd1c065d2037919a7da67baf55cc683fee09f0 upstream. Recent FITRIM work, namely bbbf7243d62d ("btrfs: combine device update operations during transaction commit") combined the way certain operations are recoded in a transaction. As a result an ASSERT was added in dev_replace_finish to ensure the new code works correctly. Unfortunately I got reports that it's possible to trigger the assert, meaning that during a device replace it's possible to have an unfinished chunk allocation on the source device. This is supposed to be prevented by the fact that a transaction is committed before finishing the replace oepration and alter acquiring the chunk mutex. This is not sufficient since by the time the transaction is committed and the chunk mutex acquired it's possible to allocate a chunk depending on the workload being executed on the replaced device. This bug has been present ever since device replace was introduced but there was never code which checks for it. The correct way to fix is to ensure that there is no pending device modification operation when the chunk mutex is acquire and if there is repeat transaction commit. Unfortunately it's not possible to just exclude the source device from btrfs_fs_devices::dev_alloc_list since this causes ENOSPC to be hit in transaction commit. Fixing that in another way would need to add special cases to handle the last writes and forbid new ones. The looped transaction fix is more obvious, and can be easily backported. The runtime of dev-replace is long so there's no noticeable delay caused by that. Reported-by: David Sterba Fixes: 391cd9df81ac ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman

btrfs: drop the lock on error in btrfs_dev_replace_cancel

2019-02-25T13:13:41Z

We should drop the lock on this error path. This has been found by a static tool. The lock needs to be released, it's there to protect access to the dev_replace members and is not supposed to be left locked. The value of state that's being switched would need to be artifically changed to an invalid value so the default: branch is taken. Fixes: d189dd70e255 ("btrfs: fix use-after-free due to race between replace start and cancel") CC: stable@vger.kernel.org # 5.0+ Reviewed-by: Anand Jain Signed-off-by: Dan Carpenter Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: merge btrfs_find_device and find_device

2019-02-25T13:13:24Z

Both btrfs_find_device() and find_device() does the same thing except that the latter does not take the seed device onto account in the device scanning context. We can merge them. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: refactor btrfs_find_device() take fs_devices as argument

2019-02-25T13:13:23Z

btrfs_find_device() accepts fs_info as an argument and retrieves fs_devices from fs_info. Instead use fs_devices, so that this function can be used in non-mount (during device scanning) context as well. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: Fix typos in comments and strings

2018-12-17T13:51:50Z

The typos accumulate over time so once in a while time they get fixed in a large patch. Signed-off-by: Andrea Gelmini Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: dev-replace: open code trivial locking helpers

2018-12-17T13:51:45Z

The dev-replace locking functions are now trivial wrappers around rw semaphore that can be used directly everywhere. No functional change. Signed-off-by: David Sterba

btrfs: dev-replace: remove custom read/write blocking scheme

2018-12-17T13:51:45Z

After the rw semaphore has been added, the custom blocking using ::blocking_readers and ::read_lock_wq is redundant. The blocking logic in __btrfs_map_block is replaced by extending the time the semaphore is held, that has the same blocking effect on writes as the previous custom scheme that waited until ::blocking_readers was zero. Signed-off-by: David Sterba

btrfs: dev-replace: swich locking to rw semaphore

2018-12-17T13:51:44Z

This is the first part of removing the custom locking and waiting scheme used for device replace. It was probably copied from extent buffer locking, but there's nothing that would require more than is provided by the common locking primitives. The rw spinlock protects waiting tasks counter in case of incompatible locks and the waitqueue. Same as rw semaphore. This patch only switches the locking primitive, for better bisectability. There should be no functional change other than the overhead of the locking and potential sleeping instead of spinning when the lock is contended. Signed-off-by: David Sterba

btrfs: don't report user-requested cancel as an error

2018-12-17T13:51:36Z

As of now only user requested replace cancel can cancel the replace-scrub so no need to log the error. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: silence warning if replace is canceled

2018-12-17T13:51:35Z

When we successfully cancel the device replace, its scrub worker returns -ECANCELED, which is then passed to btrfs_dev_replace_finishing. It cleans up based on the returned status and propagates the same -ECANCELED back the parent function. As of now only user can cancel the replace-scrub, so its ok to silence the warning here. Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba