linux-kernel - Re: Regression with orderly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130312191118.GA17439@redhat.com>
Date:	Tue, 12 Mar 2013 20:11:18 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>
Cc:	Lucas De Marchi <lucas.de.marchi@...il.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>, david@...son.dropbear.id.au,
	Kees Cook <keescook@...omium.org>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Feng Hong <hongfeng@...vell.com>,
	Lucas De Marchi <lucas.demarchi@...fusion.mobi>
Subject: Re: Regression with orderly_poweroff()

On 03/12, Linus Torvalds wrote:
>
> On Tue, Mar 12, 2013 at 11:22 AM, Oleg Nesterov <oleg@...hat.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/