From owner-freebsd-stable@FreeBSD.ORG Wed May 26 15:30:12 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E94A16A4CE; Wed, 26 May 2004 15:30:12 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1529E43D3F; Wed, 26 May 2004 15:30:12 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i4QMSh3c028132; Wed, 26 May 2004 18:28:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i4QMSgx0028129; Wed, 26 May 2004 18:28:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 26 May 2004 18:28:42 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <40B50CFE.8060804@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: bjohns123@msn.com cc: freebsd-stable@freebsd.org Subject: Re: KVA Issue? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2004 22:30:12 -0000 On Wed, 26 May 2004, Scott Long wrote: > Aside from the interesting words in the blog entry, I have a few > problems with his patch. First of all, I can't see how it is supposed > to fix anything. At line 191 we check to see if kbp->kb_next == NULL > and enter a big code block to handle that. At the end of the code block > (right before line 245 in his patch), we assign va = kbp->kb_next. So > here we know that it is non-null. Why you need to check for it to be > NULL is beyond me. But, suppose that it could be NULL. His solution is > to return NULL in the M_NOWAIT case and spin in the M_WAITOK case. I > assume that the point of spinning is that memory might become free at > some later time via it being freed in an interrupt handler or a swapout > completing. However, it does nothing to assure that enough interrpts > are enable to make sure that this can happen, so the result could easily > be that it spins forever. In fact. splmem() is held at that point, > which is the same as splhigh(), i.e. all interrupts are blocked. So if > this case is reached on a UP system, the only result will be that your > get a hard system freeze, not even a panic. > > Regardless, I'd like to find out from David if he knows of a testable > case for this. I'd be happy to entertain further discussion of that. What would be extremely helpful, actually, would be a bug report instead of a blog entry. That bug report would include, for example, information on the environment in which the problem was produced, how reproduceable it is, etc. I did a quick scan for PRs that might contain more information in the problem report database, and didn't immediately bump into one. If one has already been filed, a pointer would be useful, or if not, if one could be filed, that would be useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research