cvs commit: src/sys/vm vm_kern.c

[Bruce Evans]

On Mon, 16 Feb 2004, Robert Watson wrote:

> On Mon, 16 Feb 2004, Dag-Erling Smorgrav wrote:

I think you mean:

"On Mon, 16 Feb 2004, someone using Dag-Erling Smorgrav's terminal wrote:"

>
> >   Log:
> >   Don't panic if we fail to satisfy an M_WAITOK request; return 0 instead.
> >   The calling code will either handle that gracefully or cause a page fault.

This is just a bug.

> Also, this turns an easily understood and widely documented kernel panic
> message into a page fault.  Prior to this, users could google for the
> message and find documentation on increasing the size of the kernel
> address space.  Now, it requires facility with the source code in order to
> figure out what it is going on (since the page fault trace won't include
> the memory allocation).

I disagree that a panic is better than a page fault.  Page faults are
much easier to debug.  They are restartable using a debugger in all
cases, and can be made to not repeat endlessly in some cases.  But
they should not occur after M_WAITOK malloc's, since the main reason
for existence of M_WAITOK is to avoid having to handle malloc() returning
NULL.

Actually, a panic still occurs for the main consumer (malloc(9)) if
INVARIANTS is configured, and the collateral change to malloc()'s
documentation is wrong in this case.  The panic message is just even
less useful than the old one:

old panic message:
			panic("kmem_malloc(%ld): kmem_map too small: %ld total allocated",
				(long)size, (long)map->size);

new panic message (if the allocation is done by malloc()):
	if (flags & M_WAITOK)
		KASSERT(va != NULL, ("malloc(M_WAITOK) returned NULL"));

BTW, the old panic message has lots of printf format errors (sizes may
be truncated by casting them down and the casts don't even preserve
unsignedness) and style bugs (a long line and wrong continuation
indent).

Bruce