From owner-freebsd-arch@FreeBSD.ORG  Wed Jun  5 09:52:01 2013
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id AC229C81;
 Wed,  5 Jun 2013 09:52:01 +0000 (UTC)
 (envelope-from davidxu@freebsd.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
 [IPv6:2001:1900:2254:206c::16:87])
 by mx1.freebsd.org (Postfix) with ESMTP id 9F0701ECD;
 Wed,  5 Jun 2013 09:52:01 +0000 (UTC)
Received: from xyf.my.dom (localhost [127.0.0.1])
 by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r559q06g000845;
 Wed, 5 Jun 2013 09:52:00 GMT (envelope-from davidxu@freebsd.org)
Message-ID: <51AF0A62.4040206@freebsd.org>
Date: Wed, 05 Jun 2013 17:52:34 +0800
From: David Xu <davidxu@freebsd.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD i386;
 rv:17.0) Gecko/20130416 Thunderbird/17.0.5
MIME-Version: 1.0
To: John Baldwin <jhb@freebsd.org>
Subject: Re: [PATCH] Allow atomic sets of non-overlapping CPU sets for a global
 cpuset
References: <201305311216.56558.jhb@freebsd.org>
In-Reply-To: <201305311216.56558.jhb@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: arch@freebsd.org
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 09:52:01 -0000

On 2013/06/01 00:16, John Baldwin wrote:
> So there's an oddity with cpuset I've run into recently at work.  Suppose I
> have created a new cpuset and want to change the set of CPUs for that set (say
> from a mask of just CPU 1 to a mask of just CPU 2).  I can't do that
> atomically.  I have to first set the mask to contain both the old set (CPU 1)
> and the new set (CPU 2) and then change it a second time to only contain the
> new set (CPU 2).  The reason is that cpuset_modify() runs cpuset_testupdate()
> on the set it is about to modify, so when I try to change it in a single
> operation the new mask doesn't overlap with the old mask and it fails with
> EDEADLK.
>
> % cpuset -c -l 1 /bin/sh
> $ cpuset -gi
> pid -1 cpuset id: 2
> $ cpuset -g
> pid -1 mask: 1
> $ cpuset -l 2 -s 2
> cpuset: setaffinity: Resource deadlock avoided
>
> I think that the correct logic here is that we should only check descendants
> of the set we are changing, but not the set we are about to change.  The patch
> does this and allows my test case above to work:

The patch looks fine to me.