From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 1/3] kvm/ppc/booke: Hold srcu lock when calling gfn functions Date: Wed, 1 May 2013 19:30:04 -0500 Message-ID: <1367454604.29231.21@snotra> References: <20130502001553.GA2363@amt.cnet> <1367454443.29231.20@snotra> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Marcelo Tosatti , Alexander Graf , , To: Scott Wood Return-path: Received: from co9ehsobe003.messaging.microsoft.com ([207.46.163.26]:59229 "EHLO co9outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757726Ab3EBAaL convert rfc822-to-8bit (ORCPT ); Wed, 1 May 2013 20:30:11 -0400 In-Reply-To: <1367454443.29231.20@snotra> (from scottwood@freescale.com on Wed May 1 19:27:23 2013) Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On 05/01/2013 07:27:23 PM, Scott Wood wrote: > On 05/01/2013 07:15:53 PM, Marcelo Tosatti wrote: >> This is not good practice (codepaths should either hold srcu or not >> hold >> it, unconditionally). > > How is it different from moving the srcu lock into individual cases > of the switch? I just did it this way to make it easier to add new > exception types if necessary (e.g. at the time I thought I'd end up > adding exceptions which lead to instruction emulation, but I ended up > acquiring the lock further down the path in that case). > >> Can you give more details of the issue? (not obvious) > > ITLB/DTLB miss call things like gfn_to_memslot() which need the lock > (but don't grab it themselves -- that seems like the real bad > practice here...). Never mind on the parenthetical -- grabbing it themselves wouldn't work because they return RCU-protected data. -Scott