[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out in DomU)
> >> 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