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