Date: Thu, 26 Aug 1999 01:39:21 -0500 From: Alan Cox <alc@cs.rice.edu> To: Stephen McKay <syssgm@detir.qld.gov.au> Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/vm vm_map.h Message-ID: <19990826013921.D27804@cs.rice.edu> In-Reply-To: <199908250703.RAA14106@nymph.detir.qld.gov.au>; from Stephen McKay on Wed, Aug 25, 1999 at 05:03:24PM %2B1000 References: <199908231808.LAA86314@freefall.freebsd.org> <199908250703.RAA14106@nymph.detir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 25, 1999 at 05:03:24PM +1000, Stephen McKay wrote: > On Monday, 23rd August 1999, Alan Cox wrote: > > >alc 1999/08/23 11:08:35 PDT > > > > Modified files: > > sys/vm vm_map.h > > Log: > > struct vm_map: > > The lock structure cannot be the first element of the vm_map > > because this can result in livelock between two or more system > > processes trying to kmem_alloc_wait. > > Wouldn't it have been better to change the lock code to sleep on a field > within the lock structure, rather than the first byte? > Yes and no. :-) Doing as you suggest is a great idea because it could reduce the chance of this same problem happening elsewhere in the kernel. (So, I would welcome a patch that implements it.) On the other hand, this patch fixes the problem at hand and has a near-zero chance of causing any new problems. I don't feel the same way about any changes to lockmgr, and since 3.x-STABLE is subject to the same problem, I wanted to try the simplest patch, that I wouldn't worry about MFC'ing, first. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990826013921.D27804>