fput() doesn't wait for all references on the disk to be unclaimed but instead
it only schedules a worker that is supposed to cleanup resources once the device
is released.
During cache initialization we open device at least twice - to check its
properties and then to actually use it as cache. But since we use the async
fput() after the probe, the device might still be in use once we try to open it
for the second time (the second open returns -EBUSY).
Using synchronous __fput_sync() to close the device fixes the issue
__fput_sync() exists in the kernel API longer than bdev_file_open_by_path() and
the presence of the latter is the condition to use the synchronous put so it is
perfectly safe to get rid of fput() from the configure framework
Signed-off-by: Michal Mielewczyk <michal.mielewczyk@huawei.com>
