Messages in this thread | | | Date | Thu, 8 Mar 2012 16:46:41 +0100 | From | Oleg Nesterov <> | Subject | Re: 'khelper' (child) is stuck in endless loop: do_signal() and !user_mode(regs) |
| |
Hi Dmitry,
I think you are right, but I am not expert. Add Peter.
On 03/08, Dmitry ADAMUSHKA (EXT) wrote: > > Oleg, > > I'm able to reproduce this problem on x86 (32 bits)
And I guess "32 bits" is important. arch/x86/kernel/sys_i386_32.c:kernel_execve() does "int 0x80".
If do_execve() fails before start_thread() and TIF_SIGPENDING is set, entry_32.S calls do_notify_resume() and we lost.
I guess this is what you meant from the very beginning ;)
> It happens only when CONFIG_VM86 is disabled (I tried both). Supposedly, > due to the following bits of the VM86-specific code that let us break out > of the endless-loop. > > #ifdef CONFIG_VM86 > #define resume_userspace_sig check_userspace > #else > [...] > > there is the specific are-we-a-kernel-task? check here > > check_userspace: > movl PT_EFLAGS(%esp), %eax # mix EFLAGS and C > movb PT_CS(%esp), %al > andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax > cmpl $USER_RPL, %eax > jb resume_kernel # not returning to v8086 or userspace
Agreed, we need the USER_RPL check.
> So here are the patches to simulate the problem. Is this approach not > valid for one or another reason? > > Thanks in advance. > > > === copy-pasted === > > --- kernel/kmod.c.orig 2012-03-08 10:26:05.504752023 +0100 > +++ kernel/kmod.c 2012-03-08 11:25:05.028661835 +0100 > @@ -154,6 +154,15 @@ static int ____call_usermodehelper(void > /* We can run anywhere, unlike our parent keventd(). */ > set_cpus_allowed_ptr(current, cpu_all_mask); > > + printk(KERN_EMERG "Unleash the signal...\n"); > + > + /* > + * (1) here we emulate receiving a signal. > + * In the original case, a signal should be delivered from outside, > + * say, by "kill(-1, SIGKILL)" in busybox. > + */ > + send_sig(SIGUSR1, current, 0);
Yes, this kills the task, kernel_execve() can't succeed,
> /* > * Our parent is keventd, which runs with elevated scheduling priority. > * Avoid propagating that into the userspace child. > @@ -181,6 +190,19 @@ static int ____call_usermodehelper(void > > commit_creds(new); > > + /* (2) here we emulate the failure of kernel_execve(). > + * In real life, the failure can be due to a memory shortage, > + * or something else. > + * In our case, it happens when a board reboots - same as (1) above. > + */ > + retval = kernel_execve(NULL, > + (const char *const *)sub_info->argv, > + (const char *const *)sub_info->envp);
and I guess it can't even return.
> + printk(KERN_EMERG "x86 is rock-solid!"); > + flush_signals(current); > + > + /* If we survived the test, let's continue so the user should not notice. */ > retval = kernel_execve(sub_info->path, > (const char *const *)sub_info->argv, > (const char *const *)sub_info->envp); > > and another one > > --- arch/x86/kernel/signal.c.orig 2012-03-08 11:18:19.702651943 +0100 > +++ arch/x86/kernel/signal.c 2012-03-08 10:31:18.682304346 +0100 > @@ -765,8 +765,11 @@ static void do_signal(struct pt_regs *re > * X86_32: vm86 regs switched out by assembly code before reaching > * here, so testing against kernel CS suffices. > */ > - if (!user_mode(regs)) > + if (!user_mode(regs)) { > + printk(KERN_EMERG "* endless loop\n"); > + dump_stack(); > return; > + }
so yes, it enters the endless loop.
I do not know what should be fixed, kernel_execve() or system_call paths.
Oleg.
| |