[PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code
galak at kernel.crashing.org
Fri May 2 14:02:51 EST 2008
On May 1, 2008, at 6:34 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>> ok. Was just wondering how the async exception know that the signal
>> it wanted to send belonged to the particular process that is running.
> Usually the driver would have a reference to the task_struct of the
> task that should get the signal, and it would send the signal to that
> task, rather than the current task. That task could be the current
> task, of course, but it might not be.
> I can't think of a case where an asynchronous interrupt would always
> result in a signal being sent to the current task.
>>>> how do we provide someone stick a kprobe on such code today?
>> 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.
> I'd have to look more closely at the kprobes code to answer that in
> detail. I assume the kprobes exception handlers are sufficiently
> careful about what they do because they are aware they could have
> interrupted interrupt-disabled code.
Can you be a bit more specific about what we have to be careful about?
Also, how does this work in a hypervisor world that has no idea about
when it might interrupt a guest.
>>>> 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?
> Well, there's in_interrupt(), and there's the __kprobes marking, which
> is used to mark functions where kprobes must not put a breakpoint.
> Apart from that I would need to read through the kprobes code to
> comment further...
I would appreciate a review here to make sure we are ok. I'm assuming
if the current code is already safe that calling into it from a
separate exception stack isn't going to make any difference.
More information about the Linuxppc-dev