lkml.org 
[lkml]   [2007]   [Apr]   [30]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 30 Apr 2007 23:36:53 +0530
FromSrivatsa Vaddagiri <>
SubjectRe: [PATCH 0/9] Containers (V9): Generic Process Containers
On Mon, Apr 30, 2007 at 10:09:38AM -0700, Paul Menage wrote:
> Paul, is there any reason why we need to do a write_lock() on
> tasklist_lock if we're just trying to block fork, or is it just
> historical accident? Wouldn't it be fine to do a read_lock()?

Good point ..read_lock() will probably suffice in update_nodemask which
means we don't need the patch I sent earlier.

Paul (Jackson),
	This made me see another race in update_nodemask vs fork:

Lets say cpuset CS1 has only one task T1 to begin with.

update_nodemask(CS1)			T1 in do_fork()
	CPU0				     CPU1
=============================================================

					cpuset_fork();
					mpol_copy();


ntasks = atomic_read(&cs->count);
[ntasks = 2, accounting new born child T2]
cs->mems_allowed = something;
set_cpuset_being_rebound()


write/read_lock(tasklist_lock);


do_each_thread {
	/* Finds only T1 */
	mmarray[] = ..

} while_each_thread();
write/read_unlock(tasklist_lock);

					write_lock(tasklist_lock);

					/* Add T2, child of T1 to tasklist */
					write_unlock(tasklist_lock);


for (i = 0; i < n; i++) {
	mpol_rebind_mm(..);

}

In this for loop, we migrate only T1's ->mm. T2's->mm isn't migrated
AFAICS.

Is that fine?

-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-04-30 20:01    [from the cache]
©2003-2008