From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: Kernel bug from 3.0 (was phy disks and vifs timing
	out in DomU)
Date: Thu, 1 Sep 2011 11:38:23 -0400
Message-ID: <20110901153823.GC7506@dumpdata.com>
References: <4E4E3957.1040007@overnetdata.com>
	<20110819125615.GA26558@dumpdata.com>
	<4E56B132.9050708@overnetdata.com>
	<20110826142606.GA25511@dumpdata.com>
	<20110826144438.GA24836@dumpdata.com> <4E5E6843.7050206@citrix.com>
	<20110831170711.GB13642@dumpdata.com>
	<1314862972.28989.74.camel@zakaz.uk.xensource.com>
	<20110901142356.GD23971@dumpdata.com>
	<1314889953.28989.130.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
In-Reply-To: <1314889953.28989.130.camel@zakaz.uk.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: Todd Deshane <todd.deshane@xen.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jeremy Fitzhardinge <jeremy@goop.org>, David Vrabel <david.vrabel@citrix.com>, Anthony Wright <anthony@overnetdata.com>
List-Id: xen-devel@lists.xenproject.org

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