This reverts commit 86a03bee1d.
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>
Make umount -f more compatible with util-linux 2.22.2.
Before:
* 'umount -f': calls umount syscall,
if it fails calls umount2 with 'MNT_FORCE'
* 'mount -f -l': calls umount syscall,
if it fails calls umount2 with 'MNT_LAZY'. 'MNT_FORCE' dropped
After:
* 'umount -f': calls umount2 syscall with 'MNT_FORCE'
* 'mount -f -l': calls umount2 syscall with 'MNT_LAZY' and 'MNT_FORCE'
function old new delta
umount 45 - -45
umount_main 610 555 -55
Signed-off-by: Anton Bondarenko <anton.bondarenko@axis.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This change retains "or later" state! No licensing _changes_ here,
only form is adjusted (article, space between "GPL" and "v2" and so on).
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
(closes bug 1604)
umount: do not try to free loop device or erase mtab if remounted ro
umount: do not complain several times about the same mountpoint
function old new delta
umount_main 646 638 -8
packed_usage 23662 23652 -10
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-18) Total: -18 bytes
It is impossible to formulate sane ABI based on
size of ulong because it can be 32-bit or 64-bit.
Basically it means that you cannot portably use
more that 32 option chars in one call anyway...
Make it explicit.
except that we still have to work when there is no mtab.
Oh, and while we're at it, take advantage of the fact that modern processors
avoid branches via conditional assignment where possible. ("x = a ? b : c;"
turns into "x = c; if (a) x = b;" because that way there's no branch to
potentially mispredict and thus never a bubble in the pipeline. The if(a)
turns into an assembly test followed by a conditional assignment (rather
than a conditional jump).) So since the compiler is going to do that _anyway_,
we might as well take advantage of it to produce a slightly smaller binary.
So there.
a failed mount. And while I'm at it, legacy mdev removal was only being done
in the _failure_ case? That can't be right. Plus minor header cleanups
and an option parsing tweak.
things like xasprintf() into xfuncs.c, remove xprint_file_by_name() (it only
had one user), clean up lots of #includes... General cleanup pass. What I've
been doing for the last couple days.
And it conflicts! I've removed httpd.c from this checkin due to somebody else
touching that file. It builds for me. I have to catch a bus. (Now you know
why I'm looking forward to Mercurial.)
fallout due to the #include <sys/mount.h>. Removed that #include from various
applets and fixed up those that were unhappy when that #include was made
because they'd block copied stuff out of it. (Sigh.)
can never be made because useMtab is initialized to 0, and all the other
assignments of that variable assign 0 to it. Any compiler that can perform
simple constant propogation on local variables will optimize away if statements
testing against that variable, thus the call to erase_mtab() will never be
made.
When compiling for arm using gcc 3.3.3 with FEATURE_MTAB_SUPPORT disabled,
the linker complains that it can't find erase_mtab(). The arm optimizer isn't
exactly the brightest member of the family, and apparently needs to be hit over
the head with a hammer to get its' attention...
