longjmp/setjmp in kernel

[Keith Owens <kaos@ocs.com.au>]

On Sun, 20 Oct 2002 11:31:35 +0100, 
Russell King <rmk@arm.linux.org.uk> wrote:
>For instance, one of my patches - the rdunzip one.  It would be _really_
>nice to get some feedback on it; it isn't perfect, because the behaviour
>of gunzip is inherently undeterministic when given bad input data.  The
>only real solution IMHO is setjmp/longjmp, which I think would suck in
>the kernel.  I would have expected _this_ to attract some comments from
>people like you.  Maybe you feel that setjmp/longjmp is an approprate
>solution.  Unfortunately, I don't know that because no one has replied
>to tell me so.

Why should setjmp/longjmp suck in kernel?  I use it in kdb to recover
from debugging errors and to quit large amounts of output without
overloading every bit of debugging code with checks for "has the user
typed q?".  It meant I had to write/modify setjmp/longjmp code to work in
the kernel for i386 and ia64, no big deal.

Given the kernel model, there are few places where setjmp/longjmp make
sense.  If the code takes locks, disables interrupts etc. then forget
setjmp, cleanup after longjmp is too messy.  But if you want to recover
from unexpected events in a large body of code which does not take
locks then it is a valid use for longjmp, especially if the code
requires several levels of function calls and you want to bail out from
a low level function.