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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Sep 01, 2011 at 04:43:05PM +0100, Ian Campbell wrote:
> 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.

Duh! I totally missed that. Sounds plausible then - let me ping Andrew Morton
on re-adding the vmalloc back.
> 
> Maybe we should add alloc_vm_area_sync and use that everywhere?

That is an option too.
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

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