On 03/12, Linus Torvalds wrote: > > On Tue, Mar 12, 2013 at 11:22 AM, Oleg Nesterov <o...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
