Re: Regression with orderly_poweroff()

[Oleg Nesterov]

On 03/12, Linus Torvalds wrote:
>
> On Tue, Mar 12, 2013 at 11:22 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
> >
> > And how this can help? The real problem is not GFP_KERNEL.
> > call_usermodehelper_exec(UMH_WAIT_EXEC) will block.
>
> Well, it's probably a starting point.
>
> You need to do the argument handling atomically, because you cannot
> delay that in a workqueue (the arguments will be long gone by the time
> the workqueue starts up).

Confused... which arguments? The only argument is poweroff_cmd, it can't
go away and kmalloc(GFP_KERNEL) is fine in work->func() ?

> So I think the fix is a combination of your
> and Lucas' code, where you first do the setup atomically (copying the
> arguments and allocating that space with GFP_ATOMIC) and then you do a
> workqueue to actually do the real work of the usermode helper thing.

OK, whatever I missed we can do this, and the pending patches from Lucas
(split allocation and call_usermodehelper_exec) makes sense anyway.

In fact we can do more. On the top of Lucas's changes we can change
call_usermodehelper_freeinfo() to not call kfree(info) unconditionally,
and then we can avoid even kmalloc(GFP_ATOMIC). Not sure this actually
makes sense though.

So do you agree that orderly_poweroff() can simply use schedule_work() ?




Btw. There is another "strange" user, arch/x86/kernel/cpu/mcheck/mce.c.
It uses mce_trigger_work to call call_usermodehelper(UMH_NO_WAIT).
Why? UMH_NO_WAIT is already atomic. And the !work_pending() check is
confusing, schedule_work(schedule_work) checks it is not pending.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/