How rootvnode is used
jamie at gritton.org
Wed Jun 18 20:59:32 UTC 2008
A closer look at rootvnode shows it's not as heavily used as I thought
it was. Almost everything uses the current process's own root directory
(fd_rdir) and occasionally its jail directory (fd_jdir).
Among the direct users of rootvnode, many explicitly want the system
ZFS for kernel threads that don't yet have a root
ZFS for opening device files, where comments say "root of the global
dounmount, if forcefully unmounting.
check_root, if chroot_allow_open_directories == 1
nfs_namei, with pubflag set.
audit_canon_path, checking if the path came from the system root.
vfs_mountroot is special, as after it sets rootvnode, I'd want to set
prison0's vnode as well (currently strategy is to keep the rootvnode
global and prison0.pr_root as "separate but equal"). The case of
dounmount forcefully unmounting the root filesystem is only a precursor
to system shutdown.
One other rootvnode user is mountcheckdirs, which will change rootvnode
if it's mounted on top of. This also checks the cdir, rdir ,and fdir of
every process in the system, and should be augmented to also check the
pr_root of every prison (including prison0). Aside from the initial
vfs_mountroot call, this is the only way rootvnode's value is ever changed.
All other uses of rootvnode involve walking up the file tree:
lookup will stop at fd_rdir or fd_jdir or fd_rootvnode when looking up
"..". It should also stop at the current prison's pr_root.
vn_fullpath1 (kern___getcwd and vn_fullpath) stop at fd_rdir or
fd_rootvnode. In addition to stopping at the current prison's pr_root,
it should check fd_jdir as well.
linux_getcwd only uses rootvnode when fd_rdir is null (which as far as I
can tell never happens in user threads, and kernel threads don't go
here). Thus it really only stops at fd_rdir. It returns an error if it
gets to real root before the process root (i.e. if an open directory was
fchdir'd to), so there's no particular need for checking prison root to
just end up giving the same error.
That leaves only four places in the kernel where prison root directories
would be checked (in addition to jail_attach of course). I should be
able to handle that, even with decent locking.
More information about the freebsd-virtualization