Silent failure of busybox mount for unknown fs type

John Williams john.williams at petalogix.com
Mon Oct 12 05:12:27 UTC 2009


On Mon, Oct 12, 2009 at 3:01 PM, Vladimir Dronnikov <dronnikov at gmail.com>wrote:

> > How about spawn() does an fstat on the target first, and immediately
> > (but silently) returns an error code if not present?  Then the caller
> > can decide what to do with it.
> >
>
> Not that simple, John. spawn() accounts for $PATH, so fstat() should
> iterate thru $PATH too. Inefficient.
> mount.c uses (at line #457)
> rc = wait4pid(spawn(args));
>
> AFAIKS, all we need is to bb_error_msg() there if rc != 0 unless -q
> (quiet mode) is given to mount.
>

OK, but there's another case that will also be a bit messy.

Looking at strace it seems that mount first attempts the mount() syscall, if
that fails then it iterates /proc/filesystems and attempts to exec
mount.<fstype>.

However, if the device is already mounted, mount() fails not because the
kernel doesn't grok the fs-type, but because the device is in use.  In that
case, we should probably fail and report the mount() syscall error
immediately, instead of pointlessly iterating /proc/filesystems looking for
helper apps.

Am I missing something else?

Thanks

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20091012/2dd95f0f/attachment-0001.htm>


More information about the busybox mailing list