Messages in this thread | | | Date | Wed, 7 Mar 2012 21:05:43 +0100 | Subject | Re: 'khelper' (child) is stuck in endless loop: do_signal() and !user_mode(regs) | From | Dmitry Adamushko <> |
| |
Hi Oleg,
> 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.
Sure, that's why I indicated 'khelper' (child).
> >> 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.
Note that kernel_execve() is backed up by a full fledged syscall (not just a function call, at least on MIPS and x86), so I assume that all the usual syscall-related stuff applies here as well.
> > 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.
!user_mode() is true. Note, the failure of kernel_execve() is one of the pre-conditions. So we have a kernel thread returning from a real syscall (hence, syscall_exit and co) with TIF_SIGPENDING.
> > Once again, I can be wrong, I'll read this email tomorrow. >
Great, thanks!
-- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |