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 12:33:55 +0200 Message-ID: <20120607103355.GA21339@redhat.com> References: <20120606132012.GB24320@hanuman.astro.su.se> <20120606163000.GD9354@burratino> <20120607064017.GA2112@hanuman.astro.su.se> <20120607073333.GF3210@burratino> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20120607073333.GF3210@burratino> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jonathan Nieder Cc: Andrew Morton , Sergio Gelato , xen-devel@lists.xensource.com, 676360@bugs.debian.org List-Id: xen-devel@lists.xenproject.org On Thu, Jun 07, 2012 at 02:33:33AM -0500, Jonathan Nieder wrote: > Sergio Gelato wrote[1]: > > > That 3.4.1-1~experimental.1 build > > (3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686 GNU/Linux) > > is even less well-behaved under Xen: I'm getting a kernel OOPS at > > EIP: [] atomic64_read_cx8+0x4/0xc SS:ESP e021:ca853c6c > > The top of the trace message unfortunately scrolled off the console before I > > could see it, and the message doesn't have time to make it to syslog (either > > local or remote). > [...] > > Non-Xen boots proceed normally. > > Yeah, apparently[2] that's caused by > > commit 26c191788f18 > Author: Andrea Arcangeli > Date: Tue May 29 15:06:49 2012 -0700 > > mm: pmd_read_atomic: fix 32bit PAE pmd walk vs pmd_populate SMP race condition > > which was also included in Debian kernel 3.2.19-1. > > [1] http://bugs.debian.org/676360 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=829016#c4 Oops, sorry I didn't imagine atomic64_read on a pmd would trip. Unfortunately to support pagetable walking with mmap_sem hold for reading, we need an atomic read on 32bit PAE if CONFIG_TRANSPARENT_HUGEPAGE=y. The only case requiring this is 32bit PAE with CONFIG_TRANSPARENT_HUGEPAGE=y at build time. If you set CONFIG_TRANSPARENT_HUGEPAGE=n temporarily you should be able to work around this as I optimized the code in a way to avoid an expensive cmpxchg8b. I guess if Xen can't be updated to handle an atomic64_read on a pmd in the guest, we can add a pmd_read paravirt op? Or if we don't want to break the paravirt interface a loop like gup_fast with irq disabled should also work but looping + local_irq_disable()/enable() sounded worse and more complex than a atomic64_read (gup fast already disables irqs because it doesn't hold the mmap_sem so it's a different cost looping there). AFIK Xen disables THP during boot, so a check on THP being enabled and falling back in the THP=n version of pmd_read_atomic, would also be safe, but it's not so nice to do it with a runtime check. Thanks, Andrea