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

Kumar Gala writes:

quoted

quoted

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?

quoted

quoted

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?

quoted

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.

quoted

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