util-linux/umount.c umount error: Invalid argument
Rob Landley
rob at landley.net
Sat Aug 19 05:06:55 UTC 2006
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.
> My idea of "umount flow" would be something like this..
> 1. Parse path from commandline, expand it. quit if fail.
Define "expand" and "fail".
> 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.
> 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.
> 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
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.
> |
> "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. :)
> > > Umount should look up mtab, either maintained or symlinked to kernel
> > > parse it, match "path" for both dir and device and if it finds a
> > > appropriate entry, use the "dir" part of that entry to umount it.
> > > This is not the case.
> >
> > let's see, if you're doing a "umount /mnt" what happens:
> >
> > parse arguments
> > line 60: open /etc/mtab and read contents into mtl. This leaves "m"
> > initialized to the last element in the list, but the list has been
> > reversed
> > so this is the start of the list for traversal purposes. If there was
> > no /etc/mtab, then m and mtl will be null.
> > line 73: If ! -a, null out m and make sure we've got at least one
> > argument.
> >
> > line 83 (in the loop starting on line 79): if m is set then we're in
> > the -a
> > case and there was an /etc/mtab. Not relevant here.
> > line 85: check for -a, and if we get here we hit EOF on /etc/mtab.
> > Again not
> > relevant.
> > Line 87: Stop if we're out of command line arguments. Again, not
> > relevant.
> > line 89: play with path. Where did path come from? Set directly from
> > argv...
> > And in this case, that's what winds up in the umount() calls.
> >
> > 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...)
> > Huh, I should add a comment that "umount /dev/hdc" will unmount _every_
> > instance of hdc, not just the most recent. Or possibly I should make
> > it so
> > you have to go "umount -a /dev/hdc" in order to get that behavior?
> > (I'm open
> > to suggestions.)
>
> I would prefer -a /dev/hdc for multiple umounts. -a would then naturally
> become "more that one umount, whatever the case". Instead of the corner
> case where you have multiple mounts on a device and just assumes that you
> want to umount them all.. since preferably umount would be called with the
> path.. not the device.. assuming umount all without -a would be strange.
Before the 2.6 kernel this wasn't an issue. In 2.4 a mount point could only
be mounted in one place. The semantics of the mainstream mount pretty much
punted.
> > 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. :)
But in this case, I could easily just be wrong. Dealing with mount/umount
makes my brain hurt after a while because it's constructed entirely of corner
cases. (The new shared subtree stuff _FAILS_ if you feed it the MS_SILENT
flag. That's a clear kernel bug, but we've got to deal with it...)
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list