util-linux/umount.c umount error: Invalid argument
Rob Landley
rob at landley.net
Sun Aug 20 19:40:12 UTC 2006
On Saturday 19 August 2006 4:41 am, Christian Melki wrote:
> Rob Landley wrote:
> > On Friday 18 August 2006 8:33 am, Christian Melki wrote:
> >>>> Shouldn't the code use m->dir in the places of "path" in the umount?
> >>> If /etc/mtab exists, yes. But if /etc/mtab doesn't exist, it still
> >>> needs to
> >>> umount something.
> >> Ok. Hmm.. I guess it depends on how nice you want to be against the
user..
> >
> > "If you umount /proc, you can't umount anything else afterwards" is a heck
of
> > a side effect, and not one I consider acceptable. When you maintain
> > an /etc/mtab you don't have that problem, but I want to encourage people
> > _not_ to use that old legacy crap. And introducing large unobvious side
> > effects is _not_ a good way to wean people off the legacy stuff.
>
> Of course you shouldnt encourage legacy stuff. That wasn't my point. My
> point was: If we dont find mtab or proc/mounts. We shouldnt assume that
> the user is stupid for not having a "db" of mountpaths and doesnt know
> mount paths himself. The umount should still succeed without mtab. A
> really small embedded system might not want mtab or /proc... I dont
> considering umount not failing without a mtab a side effect...
Exactly. If we the lookup fails to find this sucker, we should call umount
with the argument they passed. So blindly using the result of the lookup
produces the wrong behavior when the lookup fails.
How does this depend on "how nice you want to be against the user"?
> >> My idea of "umount flow" would be something like this..
> >> 1. Parse path from commandline, expand it. quit if fail.
> >
> > Define "expand" and "fail".
>
> expand in the sense of realpath or abspath if you please. Failing
> meaning that we should terminate, since the path described doesnt exist
> in our system?
mount -t tmpfs walrus tmpdir
umount walrus
Note: there is no directory called walrus, but the umount should work.
> >> 2. Read mtab if it exists (we might be nice and check for proc/mounts
> >> (ugly) if the user forgot to symlink /etc/mtab). If we dont find mtab (or
> >> proc/mounts), continue with a warning assuming the user is keeping state
> >> himself, knowing the exact mount path, double mounts etc (not devices).
> >
> > A warning which would make the binary larger and convey little information
> > ("This might or might not work"), and the "it didn't work" case is pretty
> > easy to spot afterwards.
>
> You're right. I just thought issuing "hey, you're doing this without
> mtab" with
> verbose or something would be nice..
So on a system that hasn't got one normally, we issue lots of warnings? If
the umount succeeds, we're good. If the umount fails, we give a message
anyway. What value does the warning add?
> >> 3. Assuming -a, and assuming the list is >= 1, loop through all mount
> >> paths, umounting them with umount or umount2 if used with flags,
> >
> > Off the top of my head you're forgetting the fallbacks for force and read
> > only.
>
> Most probably. :) Im completely new to busybox code and digging in umount.
There is no spec for mount/umount. I've looked. I keep meaning to write one,
but it gives me headaches...
> >> else just
> >> umount or umount2 the lookup of "path" in the parsed list of "devices"
> >
> > By "the lookup of path" do you mean the absolute path, or the one we
looked up
> > in mtab? (Which are not necessarily the same. Absolute path to a block
> > device is converted to an
> ...
> (missing a scentence?)
For some reason kmail's email composer in Ubuntu 6.06 regularly decides to go
into a CPU-eating loop and only output one character per second of what I
type. Once I get about two lines ahead I switch to another window until it's
caught up, and sometimes I forget about things when distracted.
> the one looked up in mtab if we did find one. otherwise assume that the
> commandline path is correct.
If the command line path is correct, then it shouldn't be gratuitously
absoluted, which would prevent the "umount walrus" above from working.
> > Another fun little corner case is the guy with the jffs2 partition. My
vague
> > recollection is that was mounted by MTD label because the driver
understood
> > that. The device entry there was NOT A PATH, it was something
> > like "mtd:fred". So we took the abspath of it, did NOT find that in mtab
> > (because it wasn't an abspath in mtab), and thus couldn't umount his
device
> > by device name but only by path, despite it having been _mounted_ by
device
> > name because that's what was in fstab...
> >
> > Reality is, unfortunately, complicated and full of strange corner cases.
>
> hmm.. maybe one should ignore abspath? or just use it as a safetycheck?
We have to do the abspath in order to match the mtab entries, which are
abspath.
Alas, you need to keep both around. When dealing with mount, this is often
the case. (And yes, I tested what happens if you have a relative path in
fstab, many moons ago. See "no spec, head hurt".)
> >> |
> >> "paths" as it does now and using the true "dir" in mtab as umount
argument.
> >>
> >> Of course this has to be done while paying attention to loop devices
etc..
> >> Btw. Isn't there a way to check for a loopdev instead of just issuing the
> >> ioctl?
> >
> > Nope. The ioctl is specific to loop devices and nothing else should be
using
> > that number range (according to Documentation/ioctl-number.txt in the
> > kernel). So it shouldn't hurt to call that on things that aren't loop
> > devices, it should just fail harmlessly.
> >
> > I checked. :)
>
> If you say so. ;) I just reacted agains issuing ioctls against bds that
> that aren't loopdevs. :)
I could add a test to not do that, but it's spending extra bytes to avoid a
NOP ioctl. Show me a case where it could hurt something and I'll guard
against it. I can't find one. (And the test is more complicated than it
seems, by the way...)
> >>> Right, we need a new variable...
> >> Or just checking that it isn't empty when reaching the umount calls?
> >> Hmm.. Maybe i just misunderstood you..
> >
> > I believe we don't want the abspath if we didn't find it in mtab. (I'm
not
> > quite sure about this, I need to set up a test environment ot find out
what
> > the various failures are and make sure we handle them, and I haven't got
an
> > MTD in my laptop. I believe qemu 0.8.2 can fake 'em, though...)
>
> Sounds like the correct way based on the MTD section..
I'm trying not to assume that I know what a given filesystem will do. Network
mounts don't have a block device. Ram based filesystems don't have a block
device. Synthetic filesystems (proc/sysfs/devpts and more) don't have a
block device. That field can be anything from a comment to a network
address, and blindly making an absolute path out of it is not the correct
behavior. (The MTD thing of jffs2 was just one of weird ones: there are
more.)
Now it IS possible to get a list of block backed filesystems. Mount does it.
But it doesn't help much here. Now add in --bind mounts which haven't GOT a
filesystem, or perhaps umounting a loopback mount using the name of the file
(meaning we look that up via a loop device ioctl, and no I haven't
implemented that yet...)
Sorry, not trying to be irritable, this is just really complicated...
> >>> Yes, I tested this code fairly extensively at one point. Not sure
> >>> when/why it
> >>> stopped working.
> >> Maybe the magic bitmunching aliens in the svn repository broke it. Not
> >> that uncommon. ;)
> >
> > Or the kernel changed out from under me. It's been doing that. (I really
> > thought that the kernel handled umount "/dev/hdc", but the 2.6.15 in
ubuntu
> > doesn't. Yes, I've seen kernel changes in the 2.6 series affect
mount/umount
> > semantics before. :)
>
> Found this in the umount 2 manual. :)
> In Linux 2.3.99-pre7 the call umount(device) was
> removed, leaving only umount(dir) (since now devices can be mounted in
> more than one place, so specifying the device does not suffice).
Alas, there is no spec here.
Rob
P.S. If _this_ makes your head hurt, look at how -rbind is implemented in
util-linux (recursive check for mount points in mtab, --bind each one over by
hand) and how the kernel guys insist it should be implemented (MS_BIND|
MS_RECURSIVE, which doesn't actually work when I try it).
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list