Date: Wed, 27 Mar 2002 11:02:01 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Jon Mini <mini@haikugeek.com> Cc: freebsd-smp@freebsd.org Subject: Re: Patch to "Lock struct pargs" Message-ID: <Pine.BSF.4.21.0203271039200.43629-100000@InterJet.elischer.org> In-Reply-To: <20020426213214.B405@stylus.haikugeek.com>
next in thread | previous in thread | raw e-mail | index | archive | help
My first thought was "shouldn't the args be covered by th eproc lock" and then I noticed the ref-count.. obviously shared between processes. Then I thought "well why not an sx lock? I presume most processes access these read-only. THEN I thought.. hey hang on.. processes access their args from user space.. what are we storing here? so the comments in exec() etc seem to suggest that these are not the actual args that are given to the process, but instead some small subset used for (maybe) debugging.. if this is so then once again it's really only read-only when used.. any exec with a NEW set of args will create a new one. so this is similar to the ucreds.. The only item we are protecting is the reference count. Everything else should be read-only. You should only need to lock this when you are changing the reference count. Once again an smp safe reference counting scheme would save this locking stuff.... John, can you resurect your ref-counting code so we can look at it again? I think we could use it inteh ucred case too. On Fri, 26 Apr 2002, Jon Mini wrote: > The patch below locks the process argument (struct pargs) reference > count with a mutex: > > http://people.freebsd.org/~imp/smp.pargs.diff > > Please commit. > > Thanks, > -- > Jonathan Mini > mini@haikugeek.com > > <baka^ni> Yersterday, I was ashamed of myself. Today, I am just hungry. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203271039200.43629-100000>