Re: 'khelper' (child) is stuck in endless loop: do_signal() and !user_mode(regs)

[Oleg Nesterov <oleg@redhat.com>]

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.