[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikTaYjm_xfzZkYO63Wovf9frjPAsuzwPXBtB-Tm@mail.gmail.com>
Date: Sat, 25 Dec 2010 20:59:07 +0000
From: Paul Menage <menage@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Mike Galbraith <efault@....de>,
Miklos Vajna <vmiklos@...galware.org>,
shenghui <crosslonelyover@...il.com>,
kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org,
mingo@...e.hu, Greg KH <greg@...ah.com>,
Paul Turner <pjt@...gle.com>,
Yong Zhang <yong.zhang0@...il.com>,
Li Zefan <lizf@...fujitsu.com>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Srivatsa Vaddagiri <vatsa@...ibm.com>
Subject: Re: [PATCH] sched, cgroup: Use exit hook to avoid use-after-free crash
On Fri, Dec 24, 2010 at 3:59 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> Subject: sched, cgroup: Use exit hook to avoid use-after-free crash
>
> By not notifying the controller of the on-exit move back to
> init_css_set, we fail to move the task out of the previous cgroup's
> cfs_rq. This leads to an opportunity for a cgroup-destroy to come in and
> free the cgroup (there are no active tasks left in it after all) to
> which the not-quite dead task is still enqueued.
While this patch is likely fine for solving the problem, it does add
extra work into the task exit path.
Could you instead just use the pre_destroy callback to return -EBUSY
if there are still any tasks on the cfs_rq? That way there'd only be a
penalty on cgroup destruction, which is a much rarer operation.
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