lkml.org 
[lkml]   [2012]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: '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.



\
 
 \ /
  Last update: 2012-03-07 19:55    [W:0.035 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site