Revert "umount: make -d always active, add -D to suppress it"
authorDenys Vlasenko <vda.linux@googlemail.com>
Thu, 16 Mar 2017 16:45:07 +0000 (17:45 +0100)
committerDenys Vlasenko <vda.linux@googlemail.com>
Thu, 16 Mar 2017 16:51:06 +0000 (17:51 +0100)
commita98db793cffb77a8794c854443b8fe12bad98c0a
treeeb5128d5a91ef821331fa12c8204c1d642d99daa
parentab518eea9c41235a3fcde80f3ea99669eaade621
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>
util-linux/umount.c