From owner-freebsd-hackers  Wed Mar 12 04:20:43 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id EAA07208
          for hackers-outgoing; Wed, 12 Mar 1997 04:20:43 -0800 (PST)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA07178
          for <hackers@FreeBSD.ORG>; Wed, 12 Mar 1997 04:20:36 -0800 (PST)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA26810; Wed, 12 Mar 1997 07:20:05 -0500
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed, 12 Mar 1997 07:20 EST
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id GAA21070; Wed, 12 Mar 1997 06:41:00 -0500 (EST)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id GAA25977; Wed, 12 Mar 1997 06:46:53 -0500 (EST)
Date: Wed, 12 Mar 1997 06:46:53 -0500 (EST)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199703121146.GAA25977@lakes.water.net>
To: ponds!FreeBSD.ORG!hackers, ponds!tekla.fi!sja
Subject: Re: 2.2-GAMMA (3/10/97) and the "dup alloc" problem.
Content-Type: text
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:

 Wonderful idea!  I like it...

 Perhaps we can work this into 3.0 for future such problems?
I'll probably wait for 2.2-RELEASE and then begin working there
instead of the (now ancient) 2.1.6.1 I'm working with.

 Thanks for the macros!

	- Dave Rivers -

> 
> #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
>