Messages in this thread | | | Date | Wed, 7 Mar 2012 19:46:15 +0100 | From | Oleg Nesterov <> | Subject | Re: 'khelper' (child) is stuck in endless loop: do_signal() and !user_mode(regs) |
| |
Hi Dmitry,
I can't read this email carefully now, will do tomorrow.
But,
On 03/07, Dmitry ADAMUSHKA (EXT) wrote: > > Now, the assumptions (the question is whether these are true for the recent kernels): > > 1) TIF_SIGPENDING can be set for 'khelper' while it's running in ____call_usermodehelper() > between (a) flush_signal_handlers() and (b) kernel_execve() => so TIF_SIGPENDING is set;
Yes, but it is not khelper. It is another kernel thread. Yes, its ->comm[] was copied from parent, so ps/etc can show it as khelper.
> 2) kernel_execve() can fail in ____call_usermodehelper(). > > The later one is less of an assumption; let's say, it fails due to a shortage of memory (or whatever). > > If (1) is true, then > > the pre-conditions: > > - a kernel space task; > > 'khelper' running ____call_usermodehelper() in our case. > > - TIF_SIGPENDING is set. > > A signal has been delivered, say, as a result of kill(-1, SIGKILL). > > The endless loop is as follows: > > * syscall_exit_work: > - work_pending: // start_of_the_loop
We shouldn't be here. This is the kernel thread.
And if start_thread() was already called, then
> - work_notify_sig: > - do_notify_resume() > - do_signal() ==> if (!user_mode(regs)) return; so signals are not handled
user_mode() is no longer true.
Once again, I can be wrong, I'll read this email tomorrow.
Oleg.
| |