>>> To make sure that corrupted mount won't cause harm to the user, I
>>> want to add function to validate root inode on mount [...]
>> Don't you have more or less the same issue with every other non-free
>> inode in the filesystem?
> I think the point is, when the root inode is corrupted, you can't
> unmount then filesystem.
If that were the problem, I'd expect the fix to be support for forcibly
unmounting filesystems even when they're in bizarre states like that.
Arguably that is something that should go in anyway. I long ago added
a flag to umount(8)
-R Take the special | node argument as a path to be passed directly
to unmount(2), bypassing all attempts to be smart about mechani-
cally determining the correct path from the argument. This
option is incompatible with any option that potentially unmounts
more than one filesystem, such as -a, but it can be used with -f
and/or -v. This is the only way to unmount something that does
not appear as a directory (such as a nullfs mount of a plain
file); there are probably other cases where it is necessary.
Could that be suitable for dealing with the "can't unmount" aspect, or
is there kernel work needed too? The initial post indicates that there
is crasher behaviour involved, though it's not clear to what extent
it's directly related to the "can't unmount" syndrome - the post says
it can't be unmounted, but blames umount, not unmount, so it's not
clear to me whether that's userland's fault or not.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B