[BusyBox] One more #*%(&#% umount corner case.

Rob Landley rob at landley.net
Fri Aug 5 22:29:58 UTC 2005


Ahem:  AAAAAAAAAAAAHHHHHHHH!!!!!!!!

Okay, so we snapshot /etc/mtab into a linked list in ram, which makes 
traversing it while deleting items out of it much easier.  (Especially since 
the getmntent calls aren't reentrant in ways that make my head hurt.)  The 
previous code was already doing this, and after trying to avoid it I agree 
it's necessary.

Normally, stale entries in this list that are still there after we've 
unmounted them don't cause a problem.  In theory, the only thing that has to 
free entries in this linked list is optional ENABLE_FEATURE_CLEAN_UP logic, 
and that has to traverse the whole list at the end because it has to free 
entries that we didn't umount.  In the case of "umount -a" we don't look at 
any entry twice, and normal umount entries umount are happy as well.

But, as with so much in the mount logic, there's a corner case: somebody could 
list the same thing twice on the command line:

umount /thingy /thingy

Now, even in that case it shouldn't cause a problem.  If it's not there the 
syscall should fail even if our mtab checking logic still thinks it's there 
the second time.  But how about this one?

mount -t ramfs /thingy
mount /dev/ram0 /thingy
umount /dev/ram0 /dev/ram0

Because umounts of block devices are (where possible) converted into umounts 
of the corresponding directories (which is the only way to make the "umount 
all instances of this block device" logic work; iterate through all of them), 
this translates into "umount /thingy /thingy".  And that would umount the 
ramfs.

Now, it's tempting to say "user error" for this case.  It's _really_ tempting 
to just document this as "well don't do that then".  Especially since fixing 
this would add size to umount for a corner case that's arguably user error 
anyway...

But I'd like somebody other than me to make this judgement call.  Do I fix it 
and take the size hit, or do I go "user error" and keep umount smaller?

Rob



More information about the busybox mailing list