Kumar Gala 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.

- k

More information about the Linuxppc-dev mailing list