On Fri, Feb 26, 2016 at 11:39:11AM -0500, Austin S. Hemmelgarn wrote: > That's just it though, from what I can tell based on what I've seen > and what you said above, mount(8) isn't doing things correctly in > this case. If we were to do this with something like XFS or ext4, > the filesystem would probably end up completely messed up just > because of the log replay code (assuming they actually mount the > second time, I'm not sure what XFS would do in this case, but I > believe that ext4 would allow the mount as long as the mmp feature > is off). It would make sense that this behavior wouldn't have been > noticed before (and probably wouldn't have mattered even if it had > been), because most filesystems don't allow multiple mounts even if > they're all RO, and most people don't try to mount other filesystems > multiple times as a result of this.
They most certainly do. The problem is mount(8) treatment of -o loop - you can mount e.g. ext4 many times, it'll just get you extra references to the same struct super_block from those new vfsmounts. IOW, that'll behave the same way as if you were doing mount --bind on subsequent ones. And as far as kernel is concerned, /dev/loop* isn't special in any respects; if you do explicit losetup and mount the resulting /dev/loop<n> as many times as you wish, it'll work just fine. And from the kernel POV it's not different from what it sees with -o loop; setting the loop device up is done first by separate syscall, then mount(2) for that device is issued. It's mount(8) that screws up here.
