[PATCH] [POWERPC] Rework EXC_LEVEL_EXCEPTION_PROLOG code

[Kumar Gala]

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?
>>>
>>> -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.
>
> 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.

- k