'mount -a' remounts tmpfs /tmp, clobbering old /tmp, ouch!

[Clem Taylor]

Today, I discovered a rather evil/confusing bug. If I do a 'mount -a',
busybox (snapshot from 20070312, linux-mips 2.6.16.16) will re-mount
my tmpfs /tmp dropping the current contents of /tmp. This clobbers the
ssh keys, preventing me from logging back into the device. Ouch.

I'm not sure if this is a kernel issue or a busybox issue, 'mount -a' does:
read(3, "# /etc/fstab: static file system"..., 4096) = 392
lstat64(0x49a5f8, 0x7fa76708) = -1 ENOENT (No such file or directory)
mount("proc", "/proc", "proc", MS_SILENT, NULL) = -1 EBUSY (Device or
resource busy)
lstat64(0x49a5f8, 0x7fa76708) = -1 ENOENT (No such file or directory)
mount("devpts", "/dev/pts", "devpts", MS_SILENT, "gid=5,mode=620") = -1 EBUSY
lstat64(0x49a5f8, 0x7fa76708) = -1 ENOENT (No such file or directory)
mount("tmpfs", "/tmp", "tmpfs", MS_SILENT, "mode=1777") = 0
lstat64(0x49a5f8, 0x7fa76708) = 0
mount("/dev/mtdblock3", "/identity", "cramfs", MS_RDONLY|MS_SILENT,
NULL) = -1 lstat64(0x49a5f8, 0x7fa76708) = 0
mount("/dev/mtdblock4", "/nv", "jffs2", MS_SILENT, NULL) = -1

So busybox mount is just (re-)mounting all the devices, most mount
points return EBUSY, but the tmpfs mount happily does the mount. This
creates a new tmpfs file system, clobbering (orphaning?) the old one.
On my desktop machine, util-linux 'mount -a' does not seem to attempt
to remount already mounted file systems.

The only reason I was running 'mount -a' was because the USB storage
device doesn't exist when the intial mount command was run, once the
USB devices are discovered, I wanted to mount any missing filesystems.

Should busybox be more careful with what it attempts to mount or
should tmpfs check if the filesystem is already mounted? Running
'mount -a' more then once seems perfectly reasonable to me...

                             Thanks,
                             Clem