From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: cpupools and locking Date: Wed, 05 May 2010 07:25:51 +0200 Message-ID: <4BE1015F.8050901@ts.fujitsu.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap , Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 05/04/2010 08:51 PM, George Dunlap wrote: > Something seems not quite right about the cpupool locking... in > xen/common/cpupool.c:cpupool_do_domctl(), the cpupool_lock is only > held during the find for several operations. Doesn't that mean that, > for instance, it's possible for someone to call CPUPOOL_OP_DESTROY, > while someone concurrently calls CPUPOOL_OP_INFO, such that in the > INFO case, the find succeeds, but the structure is shortly thereafter > freed by DESTROY, even though INFO code still has a pointer to it > which may be dereferenced? I don't see any reference counting... am I > missing something? cpupool_do_domctl is called always while the domctl lock is being held. Maybe I should have added a comment to document this assumption. Keir's patch to move the cpupool commands to the sysctl interface makes a change of the locking mandatory. I'll setup a patch for this. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html