| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Kernel bug from 3.0 (was phy disks and vifs timing out i
> > > 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home