lkml.org 
[lkml]   [2012]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: 'khelper' (child) is stuck in endless loop: do_signal() and !user_mode(regs)
From
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/

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