From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758761Ab3B1QZp (ORCPT ); Thu, 28 Feb 2013 11:25:45 -0500 Received: from terminus.zytor.com ([198.137.202.10]:38619 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755380Ab3B1QZn (ORCPT ); Thu, 28 Feb 2013 11:25:43 -0500 Message-ID: <512F84AC.503@zytor.com> Date: Thu, 28 Feb 2013 08:24:12 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Borislav Petkov , Boris Ostrovsky , Konrad Rzeszutek Wilk , Greg KH , mingo@redhat.com, tglx@linutronix.de, xen-devel@lists.xen.org, linux-kernel@vger.kernel.org, samu.kallio@aberdeencloud.com, kraman@redhat.com, jwboyer@redhat.com Subject: Re: Is: x86: mm: Fix vmalloc_fault oops during lazy MMU updates Was: Re: [PATCH] mm/x86: Flush lazy MMU when DEBUG_PAGEALLOC is set References: <91983d94-7b7d-4a0b-9470-e7cd823ba139@default> <512E8B41.8000504@zytor.com> <20130227230009.GA32465@kroah.com> <512E91B7.6060102@zytor.com> <20130228142910.GA32354@phenom.dumpdata.com> <20130228153846.GA9782@pd.tnic> <512F7D88.4090703@zytor.com> <20130228161057.GC9767@pd.tnic> <512F83C4.6080904@oracle.com> <20130228162227.GD9767@pd.tnic> In-Reply-To: <20130228162227.GD9767@pd.tnic> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/28/2013 08:22 AM, Borislav Petkov wrote: > On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote: >> On 02/28/2013 11:10 AM, Borislav Petkov wrote: >>> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote: >>>> At the very least we should have an early filter for the **COMMON!** >>>> case that we are not on a PV platform. >>> ... or, patch it out with the alternatives on baremetal, as Steven >>> suggested. >>> >> I think making a check for paravirt_enabled() is safe enough. I'll >> send a patch shortly. > > Why not make it absolutely for free? That makes more sense, I think... although of course, there is a cost in complexity. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.