diff options
| author | Stanislav Brabec | 2016-04-12 20:22:56 +0200 |
|---|---|---|
| committer | Karel Zak | 2016-04-22 12:50:14 +0200 |
| commit | bdf46c4df9aa9201afce6ae29f72268c54293bd7 (patch) | |
| tree | 3032bf4e4caba758e27fbd19bc82031a5e7ab9b3 /sys-utils/mount.c | |
| parent | libmount: Re-organize is_mounted_same_loopfile() (diff) | |
| download | kernel-qcow2-util-linux-bdf46c4df9aa9201afce6ae29f72268c54293bd7.tar.gz kernel-qcow2-util-linux-bdf46c4df9aa9201afce6ae29f72268c54293bd7.tar.xz kernel-qcow2-util-linux-bdf46c4df9aa9201afce6ae29f72268c54293bd7.zip | |
libmount: reuse existing loop device
According to the Al Viro[1], kernel has no way to detect that a single file is
used by multiple loop devices, and multiple mounts of the same file using
different loop devices will result in a data corruption. Exactly this now
happens, if multiple btrfs sub-volumes in one file are mounted with "-oloop".
Make use of multiple -oloop mounting the same file safe: Do a loop devices
lookup, and if a loop device is already initialized, use it.
Hopefully it is possible, as "losetup -d" will return OK, even if the device
itself is in use, and is not released.
Problems:
There is a risk of race condition between the lookup and real mount.
Once loop device is initialized read-only, kernel offers no way to turn it to
read-write. It has to fail.
References:
https://lkml.org/lkml/2016/2/26/897
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz>
Diffstat (limited to 'sys-utils/mount.c')
0 files changed, 0 insertions, 0 deletions