util-linux/umount.c umount error: Invalid argument
Rob Landley
rob at landley.net
Thu Aug 17 19:10:29 UTC 2006
On Thursday 17 August 2006 7:42 am, Christian Melki wrote:
> Hi.
>
> Im looking at umount.c
/me runs, hides...
> and tracing output from the busybox umount to find
> that busybox umount uses a expanded version of "path" used at the command
> line to umount whatever target we are looking at.
http://busybox.net/downloads/patches/svn-13880.patch
> This leads to problems that I have seen a few people
> have. "umount /dev/sda1" -> -1: Invalid argument from the call oldumount.
> 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.
> 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...
> It will parse and match the "path" from mtab. But when calling the actual
> umount it will use the "path" which is the /dev/sda1 from commandline.
> I patched umount and used m->dir instead of path in umounts and it
> started behaving as expected.
I wouldn't call it simple, but most of the logic's already there. We have to
make sure we're matching the _last_ entry in the list, not the first. (Then
again I think I'm reversing the list when reading it in to make sure that
things happen in the right order.) Yes you can have two mounts on the same
directory: that's an overmount and we have to support it.
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.)
Yes, I tested this code fairly extensively at one point. Not sure when/why it
stopped working.
> My problem is; it cant be this obvious? is there some glibc trickery for
> umount(); that make them work for device paths instead of file system
> paths on certain systems or what?
Even if it is, if it's not working now (and I just tried it on Ubuntu and it
didn't) then we can't depend on it.
Try http://busybox.net/downloads/patches/svn-15806.patch
> best regards,
> Christian
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list