[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6599ad830612010925w17f56643n8c92f179ea28b828@mail.gmail.com>
Date: Fri, 1 Dec 2006 09:25:54 -0800
From: "Paul Menage" <menage@...gle.com>
To: vatsa@...ibm.com
Cc: akpm@...l.org, pj@....com, sekharan@...ibm.com, dev@...ru,
xemul@...ru, ckrm-tech@...ts.sourceforge.net,
linux-kernel@...r.kernel.org, mbligh@...gle.com, winget@...gle.com,
rohitseth@...gle.com, devel@...nvz.org,
"Ingo Molnar" <mingo@...e.hu>,
"Nick Piggin" <nickpiggin@...oo.com.au>,
Dipankar <dipankar@...ibm.com>,
"Balbir Singh" <balbir@...ibm.com>
Subject: Re: [Patch 1/3] Miscellaneous container fixes
On 12/1/06, Srivatsa Vaddagiri <vatsa@...ibm.com> wrote:
> This patches fixes various bugs I hit in the recently posted container
> patches.
>
> 1. If a subsystem registers with fork/exit hook during bootup (much
> before rcu is initialized), then the resulting synchronize_rcu() in
> container_register_subsys() hangs. Avoid this by not calling
> synchronize_rcu() if we arent fully booted yet.
>
> 2. If cpuset_create fails() for some reason, then the resulting
> call to cpuset_destroy can trip. Avoid this by initializing
> container->...->cpuset pointer to NULL in cpuset_create().
>
> 3. container_rmdir->cpuset_destroy->update_flag can deadlock on
> container_lock(). Avoid this by introducing __update_flag, which
> doesnt take container_lock().
Ah - this may be the lockup that PaulJ hit.
Thanks for these fixes.
Paul
-
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