Re: APP cannot be interrupted to gdb console by contrl+c, if APP enters into kernel mode via ioctl.
Paul Koning via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
> On Feb 2, 2021, at 11:13 PM, He Leon <[email protected]> wrote: > > Paul, > > Thanks for your reply. > > 1) APP cannot capture interrupt: for current *PROCESS* or for current *THREAD*? > > For multi-thread secario, if current thread stays inside ioctl and other threads are not. Can "contrl+c" work for gdb and switch to other thread? > I have checked this, seems not work. Process, I believe. Signals are delivered to a process. > > 2) Actually my ioctl is very simple, only inifinit loop of "printk()" or "msleep()", how it impacts "interruptible" attribution? > > seem if not quit from ioctl, "control+c" doesn't work. > I have even added "set_current_state(TASK_INTERRUPTIBLE)" in ioctl, still doesn't work. I don't know Linux drivers (is this Linux?). In the operating systems I know, a thread isn't interruptible in kernel mode. That makes sense, in kernel mode there can be kernel state being modified, and to allow the thread to be interrupted in the middle of that would make the OS state invalid. So typically syscalls or drivers have to allow explicitly for interrupts at specific points in their execution. If they do, an interrupt can take effect but only at those points; if they don't do this then the operation isn't interruptible at all and Control/C doesn't take effect until the thread returns to user mode. Again, that's a general statement; I don't know the Linux specifics. paul