[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49E7A377.3000901@linux.intel.com>
Date: Thu, 16 Apr 2009 14:30:31 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Greg KH <gregkh@...e.de>
CC: Hugh Dickins <hugh@...itas.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
alan@...rguk.ukuu.org.uk, viro@...IV.linux.org.uk,
jmorris@...ei.org, akpm@...ux-foundation.org,
paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: Please revert kobject_uevent UMH_NO_WAIT
Greg KH wrote:
> On Thu, Apr 16, 2009 at 09:55:29PM +0100, Hugh Dickins wrote:
>> Please revert commit f520360d93cdc37de5d972dac4bf3bdef6a7f6a7
>> "kobject: don't block for each kobject_uevent".
>>
>> Tetsuo Handa, running a kernel with CONFIG_DEBUG_PAGEALLOC=y
>> and CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug, has been hitting RCU
>> detected CPU stalls: it's been spinning in the loop where do_execve()
>> counts up the args (but why wasn't fixup_exception working? dunno).
>>
>> The recent change, switching kobject_uevent_env() from UMH_WAIT_EXEC
>> to UMH_NO_WAIT, is broken: the exec uses args on the local stack here,
>> and an env which is kfreed as soon as call_usermodehelper() returns.
>> It very much needs to wait for the exec to be done.
>>
>> Or keep the UMH_NO_WAIT, and complicate the code to allocate and free
>> these resources correctly? No, as GregKH pointed out when making the
>> commit, CONFIG_UEVENT_HELPER_PATH="" is a much better optimization -
>> though some distros are still saying /sbin/hotplug in their .config,
>> yet with no such binary in their initrd or their root.
>>
>> Or...
>>
>> [PATCH] revert kobject_uevent UMH_NO_WAIT
>>
>> Reported-by: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
>> Signed-off-by: Hugh Dickins <hugh@...itas.com>
>
> Acked-by: Greg Kroah-Hartman <gregkh@...e.de>
Acked-by: Arjan van de Ven <arjan@...ux.intel.com>
as well
not worth the hassle if this breaks too much
--
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/
Powered by blists - more mailing lists