Re: Regression with orderly_poweroff()

2013-03-12 Thread Oleg Nesterov
On 03/12, Linus Torvalds wrote: > > So yeah, I guess > everything could just go into a workqueue. OK, I'll try to make the patch tomorrow. Should be trivial but it is not clear how we should pass "bool force" without allocating the work_struct which would be nice to avoid. And I am a bit worried

Re: Regression with orderly_poweroff()

2013-03-12 Thread Andi Kleen
> 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. I think you're r

Re: Regression with orderly_poweroff()

2013-03-12 Thread Benjamin Herrenschmidt
On Tue, 2013-03-12 at 07:46 -0700, Linus Torvalds wrote: > > Hmm.. You should really have cc'd the people who acked it and were in > the sign-off chain too, because all those people are involved with the > patch as well. Ah oops, my bad, just used David's original CC list, too much stuff on my pl

Re: Regression with orderly_poweroff()

2013-03-12 Thread Linus Torvalds
On Tue, Mar 12, 2013 at 12:11 PM, Oleg Nesterov wrote: > > Confused... which arguments? The only argument is poweroff_cmd, it can't > go away and kmalloc(GFP_KERNEL) is fine in work->func() ? Hmm. I guess in this particular situation, we really don't have any arguments from callers, no. I was con

Re: Regression with orderly_poweroff()

2013-03-12 Thread Oleg Nesterov
On 03/12, Linus Torvalds wrote: > > On Tue, Mar 12, 2013 at 11:22 AM, Oleg Nesterov 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 a

Re: Regression with orderly_poweroff()

2013-03-12 Thread Linus Torvalds
On Tue, Mar 12, 2013 at 11:22 AM, Oleg Nesterov 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 wo

Re: Regression with orderly_poweroff()

2013-03-12 Thread Oleg Nesterov
On 03/12, Lucas De Marchi wrote: > > I have some pending patches on LKML to remove > call_usermodehelper_fns() and export call_usermodehelper_{setup,exec}. > Doing this we can separate the allocation part using GFP_ATOMIC But this is pointless. Contrary, we should change __orderly_poweroff() to d

Re: Regression with orderly_poweroff()

2013-03-12 Thread Lucas De Marchi
On Tue, Mar 12, 2013 at 11:46 AM, Linus Torvalds wrote: > On Mon, Mar 11, 2013 at 8:25 PM, Benjamin Herrenschmidt > wrote: >> >> A couple of weeks ago, David sent an email that went unanswered about a >> regression concerning orderly_poweroff(). I think the original patch >> causing it should be

Re: Regression with orderly_poweroff()

2013-03-12 Thread Oleg Nesterov
On 03/12, Linus Torvalds wrote: > > On Mon, Mar 11, 2013 at 8:25 PM, Benjamin Herrenschmidt > wrote: > > > > A couple of weeks ago, David sent an email that went unanswered about a > > regression concerning orderly_poweroff(). I think the original patch > > causing it should be reverted, here's th

Re: Regression with orderly_poweroff()

2013-03-12 Thread Linus Torvalds
On Mon, Mar 11, 2013 at 8:25 PM, Benjamin Herrenschmidt wrote: > > A couple of weeks ago, David sent an email that went unanswered about a > regression concerning orderly_poweroff(). I think the original patch > causing it should be reverted, here's the actual email with the > explanation: Hmm..