From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Subject: Re: [PATCH] KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT Date: Mon, 21 Nov 2016 16:07:33 +1100 Message-ID: <20161121050733.GN26748@fergus.ozlabs.ibm.com> References: <20161116054328.ik74cdnkvd37yxej@oak.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org Return-path: Received: from ozlabs.org ([103.22.144.67]:44259 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbcKUFIg (ORCPT ); Mon, 21 Nov 2016 00:08:36 -0500 Content-Disposition: inline In-Reply-To: <20161116054328.ik74cdnkvd37yxej@oak.ozlabs.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Nov 16, 2016 at 04:43:28PM +1100, Paul Mackerras wrote: > The hashed page table MMU in POWER processors can update the R > (reference) and C (change) bits in a HPTE at any time until the > HPTE has been invalidated and the TLB invalidation sequence has > completed. In kvmppc_h_protect, which implements the H_PROTECT > hypercall, we read the HPTE, modify the second doubleword, > invalidate the HPTE in memory, do the TLB invalidation sequence, > and then write the modified value of the second doubleword back > to memory. In doing so we could overwrite an R/C bit update done > by hardware between when we read the HPTE and when the TLB > invalidation completed. To fix this we re-read the second > doubleword after the TLB invalidation and OR in the (possibly) > new values of R and C. We can use an OR since hardware only ever > sets R and C, never clears them. > > This race was found by code inspection. In principle this bug could > cause occasional guest memory corruption under host memory pressure. > > Fixes: a8606e20e41a ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29) > Cc: stable@vger.kernel.org # v3.19+ > Signed-off-by: Paul Mackerras Applied to kvm-ppc-next. Paul.