On Monday, 18. June 2007, you wrote:
> On Monday, 18 June 2007 12:51, Uli Luckas wrote:
> > On Sunday, 17. June 2007, you wrote:
> > > On Friday, 15 June 2007 23:36, Rafael J. Wysocki wrote:
> > > > On Friday, 15 June 2007 15:08, Uli Luckas wrote:
> > > > > On Monday, 4. June 2007, Rafael J. Wysocki wrote:
> > > > > > From: Rafael J. Wysocki <[email protected]>
> > > > > >
> > > > > > Use a hibernation and suspend notifier to disable the user mode
> > > > > > helper before a hibernation/suspend and enable it after the
> > > > > > operation.
> > > > >
> > > > > Hi Rafael,
> > > > > I have a couple of questions, regarding this patch ...
> > > > >
> > > > > 2) how does your patch prevent wait_for_completion(&done) to hang
> > > > > during freezing if usermodehelper_pm_callback is called _after_ the
> > > > > above check?
> > > >
> > > > It doesn't. Once the helper is running, we can't distinguish it from
> > > > any other user land process.
> > > >
> > > > Still, it narrows the window quite a bit.
> > >
> > > Okay, I think we can help it a bit. Please tell me what you think of
> > > the following patch (on top of 2.6.22-rc4-mm2).
> >
> > Hi Rafael,
> > Thanks for your work. I haven't found the time to actually test your
> > patch but in general it looks like a valid aproach.
> > I think there is one problem though. You need to have your wait queue
> > woken up when you update (atomic_dec) running_helpers. Otherwise you end
> > up always waiting the full RUNNING_HELPERS_TIMEOUT.
>
> Yeah, right. I tend to forget about obvious things. :-(
>
Great. As far as I can see, this patch should now fix the situation except
under heavy load where it would abort the attempted suspend. I can live with
that and it is a whole lot better than it was before - Thanks.
> Besides, I think that the _pm_callback need not be compiled if CONFIG_PM is
> unset.
>
Should work but is probably beneath what you intended to do. I'll comment
further down...
> If you can, please have a look at the next version of the patch
> (appended).
>
One more topic to keep in mind for the future. None of the callers of
call_usermode_helper* expect a return value of EBUSY nor do they handle it
correctly. If auto loading of a module for example fails, a permanent error
is usually assumed and no retry attempts are made.
> Greetings,
> Rafael
>
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> ---
> kernel/kmod.c | 76
> ++++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed,
> 66 insertions(+), 10 deletions(-)
>
> Index: linux-2.6.22-rc4-mm2/kernel/kmod.c
> ===================================================================
> --- linux-2.6.22-rc4-mm2.orig/kernel/kmod.c
> +++ linux-2.6.22-rc4-mm2/kernel/kmod.c
> @@ -41,14 +41,6 @@ extern int max_threads;
>
> static struct workqueue_struct *khelper_wq;
>
> -/*
> - * If set, both call_usermodehelper_keys() and call_usermodehelper_pipe()
> exit - * immediately returning -EBUSY. Used for preventing user land
> processes from - * being created after the user land has been frozen during
> a system-wide - * hibernation or suspend operation.
> - */
> -static int usermodehelper_disabled;
> -
> #ifdef CONFIG_KMOD
>
> /*
> @@ -275,6 +267,30 @@ static void __call_usermodehelper(struct
> }
> }
>
> +#ifdef CONFIG_PM
> +/*
> + * If set and if call_usermodehelper_exec() is supposed to wait, it will
> exit + * immediately returning -EBUSY (used for preventing user land
> processes from + * being created after the user land has been frozen during
> a system-wide + * hibernation or suspend operation).
> + */
> +static int usermodehelper_disabled;
> +
> +/* Number of helpers running */
> +static atomic_t running_helpers = ATOMIC_INIT(0);
> +
> +/*
> + * Wait queue head used by usermodehelper_pm_callback() to wait for all
> running + * helpers to finish.
> + */
> +static DECLARE_WAIT_QUEUE_HEAD(running_helpers_waitq);
> +
> +/*
> + * Time to wait for running_helpers to become zero before the setting of
> + * usermodehelper_disabled in usermodehelper_pm_callback() fails
> + */
> +#define RUNNING_HELPERS_TIMEOUT (5 * HZ)
> +
> static int usermodehelper_pm_callback(struct notifier_block *nfb,
> unsigned long action,
> void *ignored)
> @@ -283,7 +299,15 @@ static int usermodehelper_pm_callback(st
> case PM_HIBERNATION_PREPARE:
> case PM_SUSPEND_PREPARE:
> usermodehelper_disabled = 1;
> - return NOTIFY_OK;
> + wait_event_timeout(running_helpers_waitq,
> + atomic_read(&running_helpers) == 0,
> + RUNNING_HELPERS_TIMEOUT);
> + if (atomic_read(&running_helpers) == 0) {
> + return NOTIFY_OK;
> + } else {
> + usermodehelper_disabled = 0;
> + return NOTIFY_BAD;
> + }
> case PM_POST_HIBERNATION:
> case PM_POST_SUSPEND:
> usermodehelper_disabled = 0;
> @@ -293,6 +317,36 @@ static int usermodehelper_pm_callback(st
> return NOTIFY_DONE;
> }
>
> +static void new_helper(void)
> +{
> + atomic_inc(&running_helpers);
> +}
> +
> +static void helper_finished(void)
> +{
> + if (atomic_dec_and_test(&running_helpers))
> + wake_up(&running_helpers_waitq);
> +}
> +
> +#else /* CONFIG_PM */
> +#define usermodehelper_disabled 0
> +
> +static inline int usermodehelper_pm_callback(struct notifier_block *nfb,
^^^^^^
This kind of implies, the compiler might optimize this function away. Further
down you call "pm_notifier(usermodehelper_pm_callback, 0);", thereby passing
a pointer to usermodehelper_pm_callback which can't be inlined nor optimized
away. If instead you had an inline function
register_usermodehelper_pm_callback which called pm_notifier if CONFIG_PM was
defined and did nothing otherwise...
> + unsigned long action,
> + void *ignored)
> +{
> + return 0;
> +}
> +
> +static inline void new_helper(void)
> +{
> +}
> +
> +static inline void helper_finished(void)
> +{
> +}
> +#endif /* CONFIG_PM */
> +
> /**
> * call_usermodehelper_setup - prepare to call a usermode helper
> * @path - path to usermode executable
> @@ -397,12 +451,13 @@ int call_usermodehelper_exec(struct subp
> DECLARE_COMPLETION_ONSTACK(done);
> int retval;
>
> + new_helper();
> if (sub_info->path[0] == '\0') {
> retval = 0;
> goto out;
> }
>
> - if (!khelper_wq || usermodehelper_disabled) {
> + if (!khelper_wq || (wait != UMH_NO_WAIT && usermodehelper_disabled)) {
> retval = -EBUSY;
> goto out;
> }
> @@ -418,6 +473,7 @@ int call_usermodehelper_exec(struct subp
>
> out:
> call_usermodehelper_freeinfo(sub_info);
> + helper_finished();
> return retval;
> }
> EXPORT_SYMBOL(call_usermodehelper_exec);
--
------- ROAD ...the handyPC Company - - - ) ) )
Uli Luckas
Software Development
ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: www.road.de
Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
