[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110831134220.GB20598@somewhere>
Date: Wed, 31 Aug 2011 15:42:24 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: rjw@...k.pl, paul@...lmenage.org, lizf@...fujitsu.com,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
containers@...ts.linux-foundation.org, matthltc@...ibm.com,
kamezawa.hiroyu@...fujitsu.com
Subject: Re: [PATCH 6/6] cgroup: kill subsys->can_attach_task(), pre_attach()
and attach_task()
On Wed, Aug 31, 2011 at 09:03:13AM +0200, Tejun Heo wrote:
> Hello, Frederic.
>
> On Tue, Aug 30, 2011 at 10:10:32PM +0200, Frederic Weisbecker wrote:
> > In order to keep the fix queued in -mm (https://lkml.org/lkml/2011/8/26/262)
> > the tasks that have failed to migrate should be removed from the iterator
> > so that they are not included in the batch in ->attach().
>
> I don't think that's a good approach. It breaks the symmetry when
> calling different callbacks. What if ->can_attach() allocates
> per-task resources and the task exits in the middle? I think we
> better lock down fork/exit/exec. I'll send patches but I'm currently
> moving / traveling w/ limited access to my toys so it might take some
> time.
My task counter subsystem patchset brings a cancel_attach_task() callback
that cancels can_attach_task() effects.
I thought that rebased on top of your patch it's going to be merged inside
cancel_attach() but OTOH we can't cancel the effect of failed migration
on a thread that way.
May be we need to keep a cancel_attach_task() just for that purpose?
--
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