[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: busybox 1.1 pre mount problem
From:       Rob Landley <rob () landley ! net>
Date:       2005-12-21 20:45:38
Message-ID: 200512211445.38203.rob () landley ! net
[Download RAW message or body]

On Wednesday 21 December 2005 05:39, yan seiner wrote:
> When I try to remount using rw, I get:

Remount is currently horked.  See my monday message "Getting remount to work 
right" (the one starting with "AAAAAAAAAAAAAHHHHH!!!!!!!").

I'm about 75% done but it exploded into a nest of nasty corner cases on me, 
_exactly_ when I wasn't prepared to deal with it.

> / # mount -o remount,rw /
> mount: Mounting  on  failed: No such file or directory

Yup.  Known issue I put about two or three hours into yesterday and a couple 
hours the day before that.  (Haven't done a darn thing on it today though.  
Just got back from christmas shopping.)

> I've tried mounting various other things; the error is always the same.
>
> / # mount /dev/mntblock/1 /home -t jffs
> mount: Mounting  on  failed: No such file or directory

That message was a "use after free" bug.  I believe I checked in the fix for 
that yesterday.  (I split off a couple of fixes that weren't directly related 
to the big nasty refactoring that getting remount to work right requires.)

Remount is big.  It's bigger than --bind or --move mounts.  It requires 
looking at /etc/mtab (I.E. /proc/mounts) rather than /etc/fstab in order to 
get the base flags/options to mount with.  (Because "mount -o 
remount,rw /dev" shouldn't _forget_ that /dev was originally mounted with 
size=100k.)  It requires stopping on the _last_ hit rather than the first hit 
(because you can overmount a given location).

And doing it _right_ requires looking at /proc/filesystems to see whether the 
filesystem type it's mounted with is nodev or not so we know whether to 
ignore the block device field (because you can remount a block device; "mount 
-o remount,ro /dev/ram0 /ramdisk" is supposed to work.  But what if somebody 
does "mount -t tmpfs /ramdisk /elsewhere" and when we're looking for a match 
to remount against we match the darn _comment_ field?

I could also test the block device to see if there actually _is_ a block 
device by that name, but what if somebody does:

  mknod /dev/walrus b 1 2
  mount /dev/walrus /thingy
  rm /dev/walrus
  remount /dev/walrus

Is that supposed to work?  (Will anybody other than me _ever_ care about this?  
I'm going to try to fix it anyway...)

I'm just trying to fix it _properly_ without adding any more size than 
absolutely necessary.  We already have code that loops 
through /etc/filesystems, if I can figure out how to re-use that in two 
places...

> It appears that mount is accessing some uninitialized string space for
> the mount, for example
>
> /proc # mount -o remount,rw /
> mount: Can't find / in /etc/fstab
>
> : Success
>
> mount: Mounting / on (null) failed: Success
>
> / # mount devfs
> mount: Mounting  on p|. failed: No such file or directory
>
> / # mount -a
> mount: Mounting  on 8a. failed: No such file or directory

It was a use after free bug that only showed up when FEATURE_CLEAN_UP was 
enabled.  Fixed in svn 12959.  (I hope, lemme know if that _doesn't_ fix it.  
It did for me...)

The remount thing I'm still poking at with a blunt stick and muttering to 
myself about...

> --Yan

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
_______________________________________________
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]