From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 2/4] KVM/MIPS32: Wrap calls to gfn_to_pfn() with srcu_read_lock/unlock() Date: Tue, 21 May 2013 11:00:47 +0300 Message-ID: <20130521080047.GV4725@redhat.com> References: <1368885266-8619-1-git-send-email-sanjayl@kymasys.com> <1368885266-8619-3-git-send-email-sanjayl@kymasys.com> <20130519125210.GI4725@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-mips@linux-mips.org, kvm@vger.kernel.org, ralf@linux-mips.org, mtosatti@redhat.com To: Sanjay Lal Return-path: Received: from mx1.redhat.com ([209.132.183.28]:13757 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751681Ab3EUIBC (ORCPT ); Tue, 21 May 2013 04:01:02 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Sun, May 19, 2013 at 10:36:32AM -0400, Sanjay Lal wrote: > > On May 19, 2013, at 8:52 AM, Gleb Natapov wrote: > > > On Sat, May 18, 2013 at 06:54:24AM -0700, Sanjay Lal wrote: > >> - As suggested by Gleb, wrap calls to gfn_to_pfn() with srcu_read_lock/unlock(). > >> Memory slots should be acccessed from a SRCU read section. > >> - kvm_mips_map_page() now returns an error code to it's callers, instead of calling panic() > >> if it cannot find a mapping for a particular gfn. > >> > >> Signed-off-by: Sanjay Lal > >> --- > >> arch/mips/kvm/kvm_tlb.c | 36 +++++++++++++++++++++++++++--------- > >> 1 file changed, 27 insertions(+), 9 deletions(-) > >> > >> diff --git a/arch/mips/kvm/kvm_tlb.c b/arch/mips/kvm/kvm_tlb.c > >> index 89511a9..ab2e9b0 100644 > >> --- a/arch/mips/kvm/kvm_tlb.c > >> +++ b/arch/mips/kvm/kvm_tlb.c > >> @@ -16,7 +16,10 @@ > >> #include > >> #include > >> #include > >> +#include > > You haven't answered it when I asked it on v2: > > Is this include still needed now when export of min_low_pfn is not > > longer here? > > > > Sorry about that, juggling too many patches, bootmem.h is no longer needed in kvm_tlb.c. Actually, I thought I had removed it before posting v3. > Should I expect new version, or can I just drop this include from the patch and apply? -- Gleb.