Date: Tue, 26 May 1998 23:22:44 +0200 From: Eivind Eklund <eivind@yes.no> To: Michael Hancock <michaelh@cet.co.jp> Cc: "John S. Dyson" <toor@dyson.iquest.net>, tlambert@primenet.com, fs@FreeBSD.ORG Subject: Re: May 17th UP machine 'panic' Message-ID: <19980526232244.10114@follo.net> In-Reply-To: <Pine.SV4.3.95.980527055424.18018A-100000@parkplace.cet.co.jp>; from Michael Hancock on Wed, May 27, 1998 at 06:02:02AM %2B0900 References: <19980526125955.35385@follo.net> <Pine.SV4.3.95.980527055424.18018A-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 27, 1998 at 06:02:02AM +0900, Michael Hancock wrote: > On Tue, 26 May 1998, Eivind Eklund wrote: > > > I'll give it a shakeout - presently it is very, very rough. It is > > only compiled, not run - and I still haven't done much to make sure > > that vput() has proc available from a higher level (even though that > > often is easy to arrange). > > It's probably safer to just use the nearest proc to the vput() in question > unless it's obvious. We can migrate to the top incrementally later as > part of other changes. I'm thinking of the cases where there isn't any source of a proc pointer in the same function, but the calling function has one. Example: ufs_checkpath() is only called from sys/ufs/ufs/ufs_vnops.c, where a suitable process pointer is available. > > I'm thinking more of whether the value of cnp->cn_proc will be the > > correct process to pass down in all cases. As it is, I haven't used > > it except where it already was used in the same function. > > That's a good strategy. cnp->cn_proc is correct in most cases but I can't > say all cases. If the vnode was ref'ed and locked in namei() it's correct > to use cnp->cn_proc. OK, I'll try to do a use-trace for calling functions to find out where things come from, and whether it can be used more places. I have only 20 functions or so that needed to use curproc; tracing use for them won't be that much work. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980526232244.10114>