[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090123102253.GF15188@elte.hu>
Date: Fri, 23 Jan 2009 11:22:53 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Paul Menage <menage@...gle.com>
Cc: akpm@...ux-foundation.org, serue@...ibm.com,
linux-kernel@...r.kernel.org, containers@...ts.osdl.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] cgroup: Fix root_count when mount fails due to busy
subsystem
* Paul Menage <menage@...gle.com> wrote:
> cgroup: Fix root_count when mount fails due to busy subsystem
>
> root_count was being incremented in cgroup_get_sb() after all error
> checking was complete, but decremented in cgroup_kill_sb(), which can be
> called on a superblock that we gave up on due to an error. This patch
> changes cgroup_kill_sb() to only decrement root_count if the root was
> previously linked into the list of roots.
>
> Signed-off-by: Paul Menage <menage@...gle.com>
>
> ---
>
> I was actually surprised to find that list_del() doesn't crash when
> run on an unattached list_head structure.
>
> kernel/cgroup.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index adcd0bb..9ce27e8 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -1115,8 +1115,10 @@ static void cgroup_kill_sb(struct super_block *sb) {
> }
> write_unlock(&css_set_lock);
>
> - list_del(&root->root_list);
> - root_count--;
> + if (!list_empty(&root->root_list)) {
> + list_del(&root->root_list);
> + root_count--;
> + }
That's ugly. It is _much_ cleaner to always keep the link head consistent
- i.e. initialize it with INIT_LIST_HEAD() and then remove from it via
list_del_init().
That way the error path will do the right thing automatically, and there's
no need for that ugly "if !list_empty" construct either.
Ingo
--
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