APP cannot be interrupted to gdb console by contrl+c, if APP enters into kernel mode via ioctl.

APP cannot be interrupted to gdb console by contrl+c, if APP enters into kernel mode via ioctl.

[He Leon]

Hi all,

I meet an issue while debugging APP by gdb.

I have a very simple APP and a very simple Kernel Mode Driver. APP accesses Kernel Mode Driver via IOCTL.

When I debug APP in User Mode by gdb, I found if APP enters and stays inside IOCTL, the APP cannot be interrupted to gdb console by control+C.

The issue is quite easy to be reproduced. I have reproduced it over different versions of kernel or gdb.

Is there such limitation for: gdb doesn't work if APP enters and stays in kernel mode?

Thanks

Re: APP cannot be interrupted to gdb console by contrl+c, if APP enters into kernel mode via ioctl.

[Paul Koning]

> On Feb 2, 2021, at 7:13 AM, He Leon via Gdb <gdb@sourceware.org> wrote:
> 
> Hi all,
> 
> I meet an issue while debugging APP by gdb.
> 
> I have a very simple APP and a very simple Kernel Mode Driver. APP accesses Kernel Mode Driver via IOCTL.
> 
> When I debug APP in User Mode by gdb, I found if APP enters and stays inside IOCTL, the APP cannot be interrupted to gdb console by control+C.
> 
> The issue is quite easy to be reproduced. I have reproduced it over different versions of kernel or gdb.
> 
> Is there such limitation for: gdb doesn't work if APP enters and stays in kernel mode?

Of course, and that is true for every debugger.  Debugger interrupt works by delivering a signal to the process.  If the process is in a state where a signal can't be delivered to it (such as in a driver operation which you have coded not to be interruptable) then the signal remains pending until the blocking operation finishes.

You probably need to do some kernel mode debugging to fix your driver first.

	paul

Re: APP cannot be interrupted to gdb console by contrl+c, if APP enters into kernel mode via ioctl.

[Paul Koning]

> On Feb 2, 2021, at 11:13 PM, He Leon <leon.he@msn.com> 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