Date: Wed, 18 Jun 2008 14:59:25 -0600 From: James Gritton <jamie@gritton.org> To: freebsd-virtualization@freebsd.org Subject: How rootvnode is used Message-ID: <4859772D.5030208@gritton.org>
next in thread | raw e-mail | index | archive | help
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 root directory: ZFS for kernel threads that don't yet have a root ZFS for opening device files, where comments say "root of the global zone". dounmount, if forcefully unmounting. vfs_mountroot. 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. - Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4859772D.5030208>