Date: Mon, 29 Sep 1997 16:05:18 +0800 From: Peter Wemm <peter@netplex.com.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Tor Egge <Tor.Egge@idi.ntnu.no>, freebsd-bugs@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: kern/4630: buffer_map might become corrupted Message-ID: <199709290805.QAA10988@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 29 Sep 1997 08:46:45 %2B0200." <242.875515605@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
>
> > This means that both vm_map_entry_dispose and vm_map_entry_create might
> > be called in an interrupt context, manipulating buffer_map and the free
> > pool of vm map entries.
>
> I think the problem here is calling brelse() at interrupt time, isn't it ?
IMHO We _really_ need some low-cost assertions of assumptions that are on
by default but can be disabled via compile option perhaps.. Kinda like an
inverse of DIAGNOSTIC.
Simple catching of things like 'must be called at splbio or greater', 'must
not be called from interrupt' etc at strategic points (eg: tsleep and the
various VM and bio utility functions etc) would help shake out these sorts
of problems once and for all.
After all, we still don't know the cause of the runqueue trashing under
2.2 unless swapping is disabled..
Perhaps a series of machine-independent macros that are implemented
per-arch as needed might help. eg:
assert_nointerrupt("tsleep");
assert_splbio("vm_function_foo()");
etc.
BTW2; I wish there was an easy way of producing a stack trace automatically
on a panic or fatal trap, or as a diagnostic tool. Having a machine panic
and reboot is near for unattended machines. Having a stack trace in the
console log would be fantastic. :-)
> Poul-Henning
>
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709290805.QAA10988>