| |
|
 |
|
 |
|
|
|
| |
|
|
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
|
|
|
| |
|
Home