From owner-freebsd-current Mon Dec 9 11:32:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA23966 for current-outgoing; Mon, 9 Dec 1996 11:32:15 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA23945 for ; Mon, 9 Dec 1996 11:32:12 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA01078; Mon, 9 Dec 1996 12:09:56 -0700 From: Terry Lambert Message-Id: <199612091909.MAA01078@phaeton.artisoft.com> Subject: Re: mfs module -- seems to work.. To: ccsanady@friley216.res.iastate.edu (Chris Csanady) Date: Mon, 9 Dec 1996 12:09:56 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@freebsd.org In-Reply-To: <199612091403.IAA00305@friley216.res.iastate.edu> from "Chris Csanady" at Dec 9, 96 08:03:26 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Ok. I did some looking into this, and now I am really stumped. There seems > to be something quite strange afoot here. :\ I have traced the problem to > vfsload(). (/usr/src/lib/libc/gen/getvfsent.c:233) It would seem that the > chdir() call is failing on a bad file descriptor!? Does anyone have any > ideas why this might happen? How a chdir("/var/tmp") ever fail? chdir works by doing a lookup, getting a locked vp to a dir back (and referenced as if it were opened -- see fchdir), and then putting the vp into the vp area for "current directory" in the proc struct. Then it closes the vp that was previously there. A currently directory is, in a very real sense, an open file. This is why you must gett all processes current directories out of an FS before it will unmount. A lookup picks a start point: For a non-chroot'ed process, this is the vp for /. For a chroot'ed process, this is the chroot vp from the proc struct (the current implementation of "namei/lookup" is inconsistent; the root vp should be set as the chroot vp, and the root vp should not be special cased for non-chroot'ed processes). The lookup proceeds a component at a time: lock start_point vnode dereference vfs_ops for lookup from the start_point my_locked_vnode = lookup(start_point, "var") unlock start_point start_point = my_locked_vnode dereference vfs_ops for lookup from the start_point my_locked_vnode = lookup(start_point, "tmp") temp_old_dir = current_dir current_dir = my_locked_vnode unlock temp_dir So to answer your question: It can fail if "var" does not exist in the root vnode namespace when lookup in the root FS type is called It can fail if "tmp" does not exist in the "var" vnode namespace when lookup in the "var" FS type is called In general, if the FS types change (ie: lookup() traverses a mount point), you should unmount the mount and look to make sure that the permissions on the underlying vnode(s) will let you cd into it, or ls it, or whatever. If not, you will need to chmod them. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.