WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out i

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU)
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Thu, 1 Sep 2011 16:43:05 +0100
Cc: Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Anthony Wright <anthony@xxxxxxxxxxxxxxx>, "Jeremy@xxxxxxxxxxxxxxxxxxxx" <Jeremy@xxxxxxxxxxxxxxxxxxxx>, David Vrabel <david.vrabel@xxxxxxxxxx>, Todd Deshane <todd.deshane@xxxxxxx>
Delivery-date: Thu, 01 Sep 2011 08:43:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110901153704.GB7506@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <4E4E3957.1040007@xxxxxxxxxxxxxxx> <20110819125615.GA26558@xxxxxxxxxxxx> <4E56B132.9050708@xxxxxxxxxxxxxxx> <20110826142606.GA25511@xxxxxxxxxxxx> <20110826144438.GA24836@xxxxxxxxxxxx> <4E5E6843.7050206@xxxxxxxxxx> <20110831170711.GB13642@xxxxxxxxxxxx> <1314862972.28989.74.camel@xxxxxxxxxxxxxxxxxxxxxx> <20110901142356.GD23971@xxxxxxxxxxxx> <4E5FA0C4.7000806@xxxxxxxxxx> <20110901153704.GB7506@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-09-01 at 16:37 +0100, Konrad Rzeszutek Wilk wrote:
> > >>     vmalloc: remove vmalloc_sync_all() from alloc_vm_area()
> > >>     
> > >>     There's no need for it: it will get faulted into the current 
> > >> pagetable
> > >>     as needed.
> > >>     
> > >>     Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
> > >>
> > >> The flaw in the reasoning here is that you cannot take a kernel fault
> > >> while processing a hypercall, so hypercall arguments must have been
> > >> faulted in beforehand and that is what the sync_all was for.
> > >>
> > >> It's probably fair to say that the Xen specific caller should take care
> > >> of that Xen-specific requirement rather than pushing it into common
> > >> code. On the other hand Xen is the only user and creating a Xen specific
> > >> helper/wrapper seems a bit pointless.
> > > 
> > > Perhaps then doing the vmalloc_sync_all() (or are more precise one:
> > > vmalloc_sync_one) should be employed in the netback code then?
> > > 
> > > And obviously guarded by the CONFIG_HIGHMEM case?
> > 
> > Perhaps. But I think the correct thing to do initially is revert the
> > change and then look at possible improvements.  Particularly as the fix
> > needs to be a backported to stable.
> 
> I disagree. Ian pointed out properly that this a Xen requirment - and there
> is no reason for us to slow down non-Xen runs with vmalloc_sync_all plucked in
> a generic path.

There is literally no other caller of alloc_vm_area than xen so you
won't be slowing anyone else down.

Maybe we should add alloc_vm_area_sync and use that everywhere?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>