Date: Wed, 12 Mar 1997 06:46:53 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!FreeBSD.ORG!hackers, ponds!tekla.fi!sja Subject: Re: 2.2-GAMMA (3/10/97) and the "dup alloc" problem. Message-ID: <199703121146.GAA25977@lakes.water.net>
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: 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703121146.GAA25977>