Date: Thu, 03 Apr 1997 19:36:05 -0800 From: David Greenman <dg@root.com> To: Terry Lambert <terry@lambert.org> Cc: current@freebsd.org Subject: Re: DISCUSS: system open file table Message-ID: <199704040336.TAA08517@root.com> In-Reply-To: Your message of "Thu, 03 Apr 1997 19:21:23 MST." <199704040221.TAA18256@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >But... currently, a vnode reference is not the same thing as an open >> >reference. >> >> Actually, for all practical purposes, it is. Ideally, everything in the >> kernel would do a "VOP_OPEN" (actually, vn_open) for internal file I/O (such >> as coredumps)...and I think we actually do now. There was a time in the >> past where this wasn't the case, however. > >Is this new since the Lite2 merge? My Lite2 tree is not on this machine, >so I can't check very easily. If it is, I need to back off until I've >had a chance to look at the Lite2 stuff... No, it happened as a result of the merged cache. It was important to have this in order to accurately track (VM) object reference counts. >The vn_open() soloution for this problem is not very nice, because it >assumes that it will be called in a process context... I can't just >pass it a manifest SUSER credential. You should be able to pass a "NOCRED" credential and escentially get that, but I'm not sure what will happen in NFS which must pass a uid. >The system open file table entry is really just a credential holder >in the kernel case, and it makes it easier to deal with the idea >of revoking a vnode: because the reference is to the system open >file table entry instead of the vnode, you can revoke the vnode >that the entry points to without notifying the people who refernced >it until the go to access the now invalid vnode. If they have a >vnode pointer instead, they have to be able to "check it" to see if >its valid, or be notified. There's no real clean failure on refernce. > >So effectively, it's not only a credential holder, its a handle that >can be invalidated out from under it. This is only true if there are no "open" instances. The vnode won't get ripped away unless it is on the free list, and it's only on the free list if noone has it "open". >This is the same thing that happens to a user space process in the >case of a forcible unmount of an FS where it has a file open. Actually, no. What happens in the forcible unmount case is that the vnode gets re-assigned to deadfs and all further reads/write return EIO. The vnode continues to remain "open" and not on the free list until all references to it have been released (usually through "close"). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704040336.TAA08517>