On May 1, 2008, at 6:34 PM, Paul Mackerras wrote:

Kumar Gala writes:

quoted

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.

quoted

quoted

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.

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.

quoted

quoted

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?

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