Messages in this thread Patch in this message | | | Date | Thu, 24 Jun 1999 14:35:30 +0100 (GMT) | From | Riley Williams <> | Subject | Re: [PATCH] *(int*)0 = 0 & variations |
| |
Hi Jeff.
>> There is also the fact that by its nature, assertion checking >> makes most of the standard oops report redundant as, if >> kassertoops was to be used, the exact circumstances would be >> known in advance. It would therefore make more sense to have two >> separate oops functions, one to deal with the current oops >> events, and a second to deal with an oops caused by a >> kassertoops() call.
> Maybe call panic() or similar, instead of oops-ing?
True - I've used panic() in the latest version.
>> Here's the corrected version:
>> +#ifdef DEBUG
> 'DEBUG' is far too general. __USING_KASSERT?
How about a kernel configuration option - or, rather, two such options. The enclosed patch (relative to the 2.2.10 kernel) adds CONFIG_KERNEL_ASSERT and CONFIG_KERNEL_ASSERT_OOPS to the alpha, arm and i386 ports in the "Kernel hacking" section, together with the latest version of the kassert() and kassertoops() macros and the relevant COnfigure.help documentation.
>> +#else >> +#define kassert(cond) (void) abs(cond) >> +#define kassertoops(cond) (void) abs(cond) >> +#endif
> Any code depending on assert evaluating the condition is broken > IMHO.
IMHO also, but the general concensus appears to be in favour of it. I've put an '#if 1'-#else-#endif block in the code, defaulting to not evaluating, but changing the '#if 1' line to '#if 0' inverts that.
> Doing so breaks an important feature of assert: it evaluates to > nothing when disabled. Your above example violates the principle > of least surprise; instead, it should be ((void)0)
Instead, it should be...
Q> #define kassert(cond)
...which just chops the whole line out.
> Once it does that, please do submit it to the Upper Penguins.
One last round of checking before I do so...
--- linux-2.2.10/include/linux/kassert.h~ Thu Jan 1 01:00:00 1970 +++ linux-2.2.10/include/linux/kassert.h Thu Jun 24 14:32:43 1999 @@ -0,0 +1,63 @@ +/* + * Include definitions for kernel assertion checking + */ + +#ifndef __KASSERT_H__ +#define __KASSERT_H__ + +#ifdef CONFIG_KERNEL_ASSERT + +/* + * Choose the reporting level to use + */ + +# define REPORT_LEVEL KERN_DEBUG + +/* + * Define the kassert() macro + */ + +# define kassert(cond) \ + if (cond) { \ + /* Do nothing */; \ + } else { \ + printk( REPORT_LEVEL "ASSERTION FAILURE: %s line %u: %s\n" \ + "Assertion = (%s)\n", \ + __FILE__, __LINE__, __FUNCTION__, #cond ); \ + } + +/* + * Define the kassertoops() macro appropriately + */ + +# ifdef CONFIG_KERNEL_ASSERT_OOPS + +# define kassertoops(cond) \ + if (cond) { \ + /* Do nothing */; \ + } else { \ + printk( REPORT_LEVEL "ASSERTION FAILURE: %s line %u: %s\n" \ + "Assertion = (%s)\n", \ + __FILE__, __LINE__, __FUNCTION__, #cond ); \ + panic("Kernel assertion failure"); \ + } + +# else + +# define kassertoops(cond) kassert(cond) + +# endif + +#else + +# if 1 +# define kassert(cond) +# else +# define kassert(cond) (void) abs(cond) +# endif + +# define kassertoops(cond) kassert(cond) + +#endif + +#endif --- linux-2.2.10/arch/i386/config.in~ Mon Apr 26 21:49:17 1999 +++ linux-2.2.10/arch/i386/config.in Thu Jun 24 14:06:00 1999 @@ -199,5 +199,11 @@ #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ + +bool 'Kernel assertion checking' CONFIG_KERNEL_ASSERT +if [ "$CONFIG_KERNEL_ASSERT" = "y" ]; then + bool ' Allow OOPS on assertion failure' CONFIG_KERNEL_ASSERT_OOPS +fi + endmenu --- linux-2.2.10/arch/i386/defconfig~ Mon Apr 12 21:12:57 1999 +++ linux-2.2.10/arch/i386/defconfig Thu Jun 24 13:45:26 1999 @@ -349,3 +349,4 @@ # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set +# CONFIG_KERNEL_ASSERT is not set --- linux-2.2.10/arch/alpha/config.in~ Sat May 22 21:41:37 1999 +++ linux-2.2.10/arch/alpha/config.in Thu Jun 24 14:05:43 1999 @@ -285,4 +285,11 @@ fi bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ + +bool 'Kernel assertion checking' CONFIG_KERNEL_ASSERT +if [ "$CONFIG_KERNEL_ASSERT" = "y" ]; then + bool ' Allow OOPS on assertion failure' CONFIG_KERNEL_ASSERT_OOPS +fi + endmenu + --- linux-2.2.10/arch/alpha/defconfig~ Sat Jun 12 19:52:51 1999 +++ linux-2.2.10/arch/alpha/defconfig Thu Jun 24 13:50:00 1999 @@ -331,3 +331,4 @@ # CONFIG_MATHEMU=y # CONFIG_MAGIC_SYSRQ is not set +# CONFIG_KERNEL_ASSERT is not set --- linux-2.2.10/arch/arm/config.in~ Thu Jan 14 18:29:28 1999 +++ linux-2.2.10/arch/arm/config.in Thu Jun 24 14:06:35 1999 @@ -217,4 +217,11 @@ bool 'Debug kernel errors' CONFIG_DEBUG_ERRORS #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ + +bool 'Kernel assertion checking' CONFIG_KERNEL_ASSERT +if [ "$CONFIG_KERNEL_ASSERT" = "y" ]; then + bool ' Allow OOPS on assertion failure' CONFIG_KERNEL_ASSERT_OOPS +fi + endmenu + --- linux-2.2.10/arch/arm/defconfig~ Thu Feb 25 18:46:46 1999 +++ linux-2.2.10/arch/arm/defconfig Thu Jun 24 13:51:03 1999 @@ -263,3 +263,4 @@ # Kernel hacking # CONFIG_MAGIC_SYSRQ=y +# CONFIG_KERNEL_ASSERT is not set --- linux-2.2.10/Documentation/Configure.help~ Mon Jun 14 03:54:06 1999 +++ linux-2.2.10/Documentation/Configure.help Thu Jun 24 14:04:30 1999 @@ -9762,6 +9762,23 @@ keys are documented in Documentation/sysrq.txt. Don't say Y unless you really know what this hack does. +Kernel assertion checking +CONFIG_KERNEL_ASSERT + If you say Y here, then any assertions made in the kernel with the + kassert() or kassertoops() macros will be checked at runtime. This + can help in locating kernel bugs, since any messages resulting from + this will indicate assumptions made by the programmers that are not + in fact true. + +Allow OOPS on assertion failure +CONFIG_KERNEL_ASSERT_OOPS + If you say Y here, then any assertions made in the kernel with the + kassertoops() macro that fail will result in an OOPS occurring once + the assertion failure has been reported. + + If you say N here, then the kassertoops() macro will behave the same + as the kassert() macro, and no OOPS will occur in this event. + ISDN subsystem CONFIG_ISDN ISDN ("Integrated Services Digital Networks", called RNIS in France)
Best wishes from Riley.
+----------------------------------------------------------------------+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this XXXX feature, but I bet someone | | else has already done so and is just about to release their patch. | +----------------------------------------------------------------------+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |