aboutsummaryrefslogtreecommitdiff
path: root/testsuite/paste
diff options
context:
space:
mode:
authorDenys Vlasenko <vda.linux@googlemail.com>2017-03-16 17:45:07 +0100
committerDenys Vlasenko <vda.linux@googlemail.com>2017-03-16 17:51:06 +0100
commita98db793cffb77a8794c854443b8fe12bad98c0a (patch)
treeeb5128d5a91ef821331fa12c8204c1d642d99daa /testsuite/paste
parentab518eea9c41235a3fcde80f3ea99669eaade621 (diff)
downloadbusybox-a98db793cffb77a8794c854443b8fe12bad98c0a.tar.gz
Revert "umount: make -d always active, add -D to suppress it"
This reverts commit 86a03bee1d3d6990c03bf500836b19ec8a1c1f12. Since now our "mount -oloop" creates AUTOCLEARed loopdevs, we no longer need our umount to destroy loopdevs to match the usual util-linux behaviour. Now this revert fixes another, opposite bug: "explicit" mount /dev/loopN and then umount must not drop loopdevs! User complaint is as follows: It seems LOOP_CLR_FD called on a loop-*partition* removes the mapping of the whole *device* - which results in the following: root@LEDE:/# loop=$(losetup -f) root@LEDE:/# echo ${loop} /dev/loop2 root@LEDE:/# losetup ${loop} /IMAGE root@LEDE:/# ls -l ${loop}* brw------- 1 root root 7, 2 Mar 6 20:09 /dev/loop2 root@LEDE:/# partprobe ${loop} root@LEDE:/# ls -l ${loop}* brw------- 1 root root 7, 2 Mar 6 20:09 /dev/loop2 brw------- 1 root root 259, 8 Mar 6 21:59 /dev/loop2p1 brw------- 1 root root 259, 9 Mar 6 21:59 /dev/loop2p2 brw------- 1 root root 259, 10 Mar 6 21:59 /dev/loop2p3 brw------- 1 root root 259, 11 Mar 6 21:59 /dev/loop2p4 brw------- 1 root root 259, 12 Mar 6 21:59 /dev/loop2p5 brw------- 1 root root 259, 13 Mar 6 21:59 /dev/loop2p6 brw------- 1 root root 259, 14 Mar 6 21:59 /dev/loop2p7 brw------- 1 root root 259, 15 Mar 6 21:59 /dev/loop2p8 root@LEDE:/# mount ${loop}p8 /MOUNT # mount loop partition root@LEDE:/# losetup -a | grep $loop # loop dev mapping still there /dev/loop2: 0 /mnt/IMAGE root@LEDE:/# strace umount /MOUNT 2> /log # unmount loop partition root@LEDE:/# losetup -a | grep ${loop} # loop device mapping is gone root@LEDE:/# grep -i loop /log open("/dev/loop2p7", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, LOOP_CLR_FD) = 0 root@LEDE:/# The strace was done to figure out, if maybe umount wrongly ioctl()'s the parent device instead of the partition - it doesn't. I already wasn't a fan of umount implicitly removing the mapping in the first place (as I usually setup and release loop devices with `losetup` and scripts needed to call umount differently in order to work and outside busybox). However taking above (kernel-)behaviour into account - umount calling ioctl(LOOP_CLR_FD) unconditionally potentially causes some nasty side effects Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Diffstat (limited to 'testsuite/paste')
0 files changed, 0 insertions, 0 deletions