Messages in this thread | | | Date | Tue, 12 Mar 2013 20:11:18 +0100 | From | Oleg Nesterov <> | Subject | Re: Regression with orderly_poweroff() |
| |
On 03/12, Linus Torvalds wrote: > > On Tue, Mar 12, 2013 at 11:22 AM, Oleg Nesterov <oleg@redhat.com> 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.
| |