From owner-freebsd-hackers  Wed Mar 12 00:36:54 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id AAA25946
          for hackers-outgoing; Wed, 12 Mar 1997 00:36:54 -0800 (PST)
Received: from lassie.eunet.fi (lassie.eunet.fi [192.26.119.7])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id AAA25939
          for <hackers@FreeBSD.org>; Wed, 12 Mar 1997 00:36:46 -0800 (PST)
Received: from marathon.tekla.fi by lassie.eunet.fi with SMTP id AA23575
  (5.67a/IDA-1.5 for <hackers@FreeBSD.org>); Wed, 12 Mar 1997 10:36:42 +0200
Received: from poveri.tekla.fi by marathon.tekla.fi (5.65/20-jun-90)
	id AA07051; Wed, 12 Mar 1997 10:36:38 +0200
From: sja@tekla.fi (Sakari Jalovaara)
Received: by poveri.tekla.fi; (5.65v3.2/1.1.8.2/20Aug96-0557PM)
	id AA32141; Wed, 12 Mar 1997 10:36:37 +0200
Date: Wed, 12 Mar 1997 10:36:37 +0200
Message-Id: <9703120836.AA32141@poveri.tekla.fi>
To: hackers@FreeBSD.org
Subject: Re: 2.2-GAMMA (3/10/97) and the "dup alloc" problem.
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

If the problem smells like incorrect splx's, maybe the kernel
could have checks in places that expect specific cpl masks.
The checks should probably be behind a kernel compilation option.
Something along the lines of:

#ifdef DEBUG_CHECK_SPL
#define assert_splx(x) \
	(void) ((cpl & (x)) == (x) || assert_spl_fail(__FILE__, __LINE__))
#define assert_splbio()   assert_splx(bio_imask)
#define assert_splclock() assert_splx(HWI_MASK | SWI_MASK)
/* etc */
#else
#define assert_splx(x)    /* nop */
#define assert_splbio()   /* nop */
#define assert_splclock() /* nop */
#endif

Plus a bit extra to handle SWI_AST?  I tried those checks in
pre-Lite2 3.0-current and got a few messages where
cpl == 1 << SWI_AST while something else was expected.

A stack trace would be much better than just printing __FILE__
and __LINE__.  I don't think panic()ing would be nice.
Perhaps something adapted from the debugger stack trace
function?

A bunch of suitable places where assert_splxxx()'s could go
can be found by grepping comments (grep -i 'at spl' *.c).
A few of the comments (or calls?) seem to be wrong; at least
those in kmem_malloc(), vm_page_unqueue() and vm_page_remove().
									++sja