lkml.org 
[lkml]   [2012]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: ipv6: tunnel: hang when destroying ipv6 tunnel
On Sun, Apr 1, 2012 at 5:21 AM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> Sasha Levin wrote:
>> While it seems that 9p is the culprit, I have to point out that this
>> bug is easily reproducible, and it happens each time due to a
>> call_usermode_helper() call. Other than that 9p behaves perfectly and
>> I'd assume that I'd be seeing other things break besides
>> call_usermode_helper() related ones.
>
> I think one of below two patches can catch the bug if this is a usermodehelper
> related bug. Please try.
>
> ----- Patch 1 -----
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 01394b6..3e63319 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -571,7 +571,7 @@ int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
>         * flag, for khelper thread is already waiting for the thread at
>         * wait_for_completion() in do_fork().
>         */
> -       if (wait != UMH_NO_WAIT && current == kmod_thread_locker) {
> +       if (WARN_ON(wait != UMH_NO_WAIT && current == kmod_thread_locker)) {
>                retval = -EBUSY;
>                goto out;
>        }
>
>
> ----- Patch 2 -----
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> index 9efeae6..1350670 100644
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -48,10 +48,10 @@ static inline int request_module_nowait(const char *name, ...) { return -ENOSYS;
>  struct cred;
>  struct file;
>
> -#define UMH_NO_WAIT    0       /* don't wait at all */
> -#define UMH_WAIT_EXEC  1       /* wait for the exec, but not the process */
> -#define UMH_WAIT_PROC  2       /* wait for the process to complete */
> -#define UMH_KILLABLE   4       /* wait for EXEC/PROC killable */
> +#define UMH_NO_WAIT    0x10    /* don't wait at all */
> +#define UMH_WAIT_EXEC  0x11    /* wait for the exec, but not the process */
> +#define UMH_WAIT_PROC  0x12    /* wait for the process to complete */
> +#define UMH_KILLABLE   0x04    /* wait for EXEC/PROC killable */
>
>  struct subprocess_info {
>        struct work_struct work;
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 957a7aa..ecfd3d5 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -483,6 +483,18 @@ int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
>        DECLARE_COMPLETION_ONSTACK(done);
>        int retval = 0;
>
> +       if (unlikely(wait == -1 || wait == 0 || wait == 1)) {
> +               WARN(1, "Requesting for usermode helper with hardcoded wait "
> +                    "flag. Change to use UMH_* symbols and recompile, or "
> +                    "this request will fail on Linux 3.4.\n");
> +               if (wait == -1)
> +                       wait = UMH_NO_WAIT;
> +               else if (wait == 0)
> +                       wait = UMH_WAIT_EXEC;
> +               else
> +                       wait = UMH_WAIT_PROC;
> +       }
> +
>        helper_lock();
>        if (sub_info->path[0] == '\0')
>                goto out;

Neither of these patches did the trick (no warnings showing up and
still seeing the hangs). However, the following patch has fixed it:

diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index 1a91efa..8ecc377 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -309,7 +309,7 @@ int kobject_uevent_env(struct kobject *kobj, enum
kobject_action action,
goto exit;

retval = call_usermodehelper(argv[0], argv,
- env->envp, UMH_WAIT_EXEC);
+ env->envp, UMH_NO_WAIT);
}

exit:
Not sure if that info helps any, but just in case.
--
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-04-01 19:37    [W:0.060 / U:10.232 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site