Re: Kernel bug from 3.0 (was phy disks and vifs timing out in DomU)

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> > > 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?
> 
> Not just netback but everywhere which uses this interface.

Which is for right now netback :-). But yes - wherever we use that
we should do follow with some sort of vmalloc.
> 
> > And obviously guarded by the CONFIG_HIGHMEM case?
> 
> I don't think this has anything to do with highmem, does it? It is
> potentially just as much of a problem on 64 bit for example.

You are right. I somehow had vmalloc == highmem equated but that is bogus.
> 
> Ian.