Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757870AbXHYQX0 (ORCPT ); Sat, 25 Aug 2007 12:23:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751908AbXHYQXR (ORCPT ); Sat, 25 Aug 2007 12:23:17 -0400 Received: from x346.tv-sign.ru ([89.108.83.215]:53586 "EHLO mail.screens.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751462AbXHYQXR (ORCPT ); Sat, 25 Aug 2007 12:23:17 -0400 Date: Sat, 25 Aug 2007 20:26:06 +0400 From: Oleg Nesterov To: Cliff Wickman , Paul Jackson , Paul Menage Cc: linux-kernel@vger.kernel.org Subject: cpuset: attach_task() vs sched_setaffinity() race? Message-ID: <20070825162606.GA2630@tv-sign.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 785 Lines: 25 After the brief look at kernel/cpuset.c, it seems that attach_task() should guarantee that the task can't use CPUs outside of cpuset->cpus_allowed. But this looks racy wrt sched_setaffinity() which does cpus_allowed = cpuset_cpus_allowed(p); // callback_mutex is free set_cpus_allowed(p); What if attach_task()->set_cpus_allowed() happens in between? Another question: update_cpumask(cs) does nothing with the tasks attached to that cpuset, why? It may take a while before the task actually migrates to the new CPU. Thanks, Oleg. - 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/