During my testing of call_usermodehelper, I noticed that
if it is called from a workqueue function, it does really wait
(when asked to) for the usermodehelper to exit.
Patch below should fix it. It has been tested against 2.6.4-rc2-mm1
on a 4-way x86 SMP box.
--- kmod.c.org 2004-03-09 18:52:19.000000000 +0530
+++ kmod.c 2004-03-09 18:52:38.000000000 +0530
@@ -258,10 +258,13 @@
if (current_is_keventd()) {
/* We can't wait on keventd! */
__call_usermodehelper(&sub_info);
- } else {
+ if (!wait)
+ goto out;
+ } else
schedule_work(&work);
- wait_for_completion(&done);
- }
+
+ wait_for_completion(&done);
+
out:
return sub_info.retval;
}
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
Srivatsa Vaddagiri <[email protected]> wrote:
>
> During my testing of call_usermodehelper, I noticed that
> if it is called from a workqueue function, it does really wait
> (when asked to) for the usermodehelper to exit.
>
> Patch below should fix it. It has been tested against 2.6.4-rc2-mm1
> on a 4-way x86 SMP box.
>
> --- kmod.c.org 2004-03-09 18:52:19.000000000 +0530
> +++ kmod.c 2004-03-09 18:52:38.000000000 +0530
> @@ -258,10 +258,13 @@
> if (current_is_keventd()) {
> /* We can't wait on keventd! */
> __call_usermodehelper(&sub_info);
> - } else {
> + if (!wait)
> + goto out;
> + } else
> schedule_work(&work);
> - wait_for_completion(&done);
> - }
> +
> + wait_for_completion(&done);
> +
> out:
> return sub_info.retval;
> }
I'm not so sure about this. There are deadlock potentials if the usermode
application wants to perform some function which requires keventd services
to complete - the application cannot complete because keventd is itself
waiting for the application.
Can we think of any circumstances under which keventd _should_
synchronously wait for the userspace app?
btw: your patch had whitespace where the tabs should be (email client
problem), and `patch -p1' format is (much) preferred.
On Tue, Mar 09, 2004 at 01:38:35PM -0800, Andrew Morton wrote:
> I'm not so sure about this. There are deadlock potentials if the usermode
> application wants to perform some function which requires keventd services
> to complete - the application cannot complete because keventd is itself
> waiting for the application.
>
> Can we think of any circumstances under which keventd _should_
> synchronously wait for the userspace app?
Honestly I don't know ..Would it be reasonable for somebody
to call request_module from a work function (in which case the above
bug is exposed)? I agree it is not a nice thing if we block keventd
waiting for the app to exit.
>
> btw: your patch had whitespace where the tabs should be (email client
> problem), and `patch -p1' format is (much) preferred.
Sorry abt that! The whitespace was because of cut-n-paste ..I have
also downloaded your patch scripts and will start using that for
generating patches henceforth!
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
On Wed, 2004-03-10 at 19:24, Srivatsa Vaddagiri wrote:
> On Tue, Mar 09, 2004 at 01:38:35PM -0800, Andrew Morton wrote:
> > I'm not so sure about this. There are deadlock potentials if the usermode
> > application wants to perform some function which requires keventd services
> > to complete - the application cannot complete because keventd is itself
> > waiting for the application.
> >
> > Can we think of any circumstances under which keventd _should_
> > synchronously wait for the userspace app?
>
> Honestly I don't know ..Would it be reasonable for somebody
> to call request_module from a work function (in which case the above
> bug is exposed)? I agree it is not a nice thing if we block keventd
> waiting for the app to exit.
I think a BUG_ON(wait) is arguably right here: anyone trying it will hit
it immediately. Perhaps a "/* keventd shouldn't block */" comment above
it would help.
Cheers,
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell