lkml.org 
[lkml]   [2009]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/6] cpuset: convert cpuset_attach() to use cpumask_var_t
On Wed, 31 Dec 2008 16:36:11 +0800 Li Zefan <lizf@cn.fujitsu.com> wrote:

> Impact: reduce stack usage
>
> Allocate a cpumask_var_t in cpuset_can_attach() and then use it in
> cpuset_attach(), so we won't fail cpuset_attach().
>
> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> ---
> kernel/cpuset.c | 31 +++++++++++++++++++++++++------
> 1 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> index afa29cf..b4c36d5 100644
> --- a/kernel/cpuset.c
> +++ b/kernel/cpuset.c
> @@ -1306,6 +1306,14 @@ static int fmeter_getrate(struct fmeter *fmp)
> return val;
> }
>
> +/*
> + * Since cpuset_attach() can't fail, we allocate a cpumask_var_t in
> + * cpuset_can_attach() and then use it in cpuset_attach().
> + *
> + * Protected by cgroup_lock.

OK, but it's a bit fragile.

How are we to ensure that all calls to cpuset_can_attach() are followed
by a call to cpuset_attach(), and how are we to ensure that both calls
are protected by the same taking of the lock? For all time?

In fact, it's broken right now, isn't it? If cgroup_attach_task()'s
call to find_css_set() fails, we leak the result of cpuset_can_attach()'s
alloc_cpumask_var()?



\
 
 \ /
  Last update: 2009-01-05 08:43    [W:0.171 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site