From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/2] kvm: use modern cpumask primitives, no cpumask_t on stack Date: Mon, 08 Dec 2008 11:49:57 +0200 Message-ID: <493CEDC5.1080004@redhat.com> References: <200812072125.14416.rusty@rustcorp.com.au> <493BF144.9080106@redhat.com> <493BF648.6060504@redhat.com> <200812081638.07526.rusty@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel , linux-kernel@vger.kernel.org, Mike Travis To: Rusty Russell Return-path: Received: from mx2.redhat.com ([66.187.237.31]:56177 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbYLHJts (ORCPT ); Mon, 8 Dec 2008 04:49:48 -0500 In-Reply-To: <200812081638.07526.rusty@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org List-ID: Rusty Russell wrote: >> Btw, for the general case, instead of forcing everyone to duplicate, how >> about: >> >> cpumask_var_t cpus; >> >> with_cpumask(cpus) { >> ... code to populate cpus >> smp_call_function_some(...); >> } end_with_cpumask(cpus); >> >> Where with_cpumask() allocates cpus, and uses a mutex + static fallback >> on failure. >> > > I'd prefer not to hide deadlocks that way :( > > I'll re-battle with that code to neaten it. There are only a few places > which have these kind of issues. > > cpuvar_get_maybe_mutex_lock(...); ... cpuvar_put_maybe_mutex_unlock(...); ? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.