Date: Wed, 12 Mar 1997 10:36:37 +0200 From: sja@tekla.fi (Sakari Jalovaara) To: hackers@FreeBSD.org Subject: Re: 2.2-GAMMA (3/10/97) and the "dup alloc" problem. Message-ID: <9703120836.AA32141@poveri.tekla.fi>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9703120836.AA32141>