[PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code

[Kumar Gala]

On May 1, 2008, at 3:24 AM, Paul Mackerras wrote:

> Kumar Gala writes:
>
>>> It depends on whether a critical or machine check handler can ever  
>>> do
>>> anything to generate a signal or a reschedule.  If they can't, then
>>> there is no problem.
>>
>> They can if the come from user space.  I'm question what it means to
>> send a signal based on receiving an async exception.
>
> The most common cases are (a) something that ultimately generates
> input on a tty (e.g. a character arriving on a serial port) and that
> input turns out to be a ^C or similar, or (b) something that signals
> I/O completion and the program doing the I/O has requested
> notification by a SIGIO.  But in general any driver code can send a
> signal to userspace if it wants.

ok.  Was just wondering how the async exception know that the signal  
it wanted to send belonged to the particular process that is running.   
But I guess there are cases that the signal is really intended for who  
ever is currently running?

>>> If they can, then we have to be very careful.  If a critical or
>>> machine check happens at a point where normal interrupts are  
>>> disabled
>>> then we have to be extremely careful not to do anything that the  
>>> code
>>> we've interrupted assumes can't happen - so we'd better not try to
>>> take any spinlocks, for example.  That severely limits what the
>>> handler can do.  It probably shouldn't even call printk, for
>>> instance, or wake any process up, and definitely shouldn't call
>>> schedule (or schedule_preempt) on the way out.

Do we ensure that synchronous exceptions will not occur in these cases  
that kernel code things interrupts are disabled in?

>> how do we provide someone stick a kprobe on such code today?
>
> -ENOPARSE

I was asking how we prevent the cases you were describing working w/ 
kprobes today.  Since it ends up single stepping in kernel codes its  
possible that someone sets a kprobe in code that shouldn't be  
interrupted, yet we'd cause a SingleStep Exception.

>> So I'm not if there is any good way to preclude the handlers
>> associated with these exceptions from doing the things you listed.
>
> In that case, you'd better expect to see system freezes, memory
> corruption and general instability.

So the case I'm trying to make work is debug and kprobes.  This case  
seems like we have pretty good control over what the "handler" does.   
Are there checks we can add to BUG_ON() so we are at least aware of  
the code attempts to do something it shouldnt?

- k