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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
