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