KVA Issue?

[Robert Watson]

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 at fledge.watson.org      Senior Research Scientist, McAfee Research