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: David Vrabel <david.vrabel@xxxxxxxxxx>
Subject: Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU)
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Thu, 1 Sep 2011 11:37:04 -0400
Cc: Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Anthony Wright <anthony@xxxxxxxxxxxxxxx>, Jeremy@xxxxxxxxxxxxxxxxxxxx, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Todd Deshane <todd.deshane@xxxxxxx>
Delivery-date: Thu, 01 Sep 2011 08:39:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E5FA0C4.7000806@xxxxxxxxxx>
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>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
> >>     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.


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