From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: xen: oops at atomic64_read_cx8+0x4 Date: Thu, 7 Jun 2012 18:17:04 +0200 Message-ID: <20120607161704.GE21339@redhat.com> References: <20120606132012.GB24320@hanuman.astro.su.se> <20120606163000.GD9354@burratino> <20120607064017.GA2112@hanuman.astro.su.se> <20120607073333.GF3210@burratino> <20120607103355.GA21339@redhat.com> <20120607155647.GO9472@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20120607155647.GO9472@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Jonathan Nieder , Andrew Morton , Sergio Gelato , xen-devel@lists.xensource.com, 676360@bugs.debian.org List-Id: xen-devel@lists.xenproject.org Hi, On Thu, Jun 07, 2012 at 11:56:47AM -0400, Konrad Rzeszutek Wilk wrote: > then the high part. Why that would trip the hypervisor > is not clear to me. Perhaps in the past it only read the That is the CONFIG_TRANSPARENT_HUGEPAGE=n case and in fact it doesn't trip the hypervisor. That was tested too, it should work fine. The problem is with the atomic64_read version, that one uses cmpxchg8b to read the contents of the pmdp. > Ah, by just skipping the thing if the low bits are zero. Yep. > didn't like somebody reading the high and low bit, but isn't the > pmdval_t still 64-bit ? So I would have thought this would The pmd format is unchanged, that's hardware. > The thing is that I did install a 32-bit PAE guest (a Fedora) on a Fedora > 17 dom0. So it looks like this is reading high part is fixed on the newer > hypervisors, but now with the older ones. And the older one is Amazon EC2 > so some .. hack to workaround older hypervisors could be added. The insn oopsing is cmpxchg8b and it's not reading the low/high part in two separate insn but reading it in a single insn, which means the kernel oopsing was built with CONFIG_TRANSPARENT_HUGEPAGE=y.