From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Kernel bug from 3.0 (was phy disks and vifs timing out in DomU) Date: Thu, 1 Sep 2011 12:07:22 -0400 Message-ID: <20110901160722.GB8715@dumpdata.com> References: <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> <4E5FA0C4.7000806@citrix.com> <20110901153704.GB7506@dumpdata.com> <1314891785.28989.133.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1314891785.28989.133.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Fitzhardinge , "xen-devel@lists.xensource.com" , Anthony Wright , "Jeremy@acsinet12.oracle.com" , David Vrabel , Todd Deshane List-Id: xen-devel@lists.xenproject.org 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 > > > >> > > > >> 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@lists.xensource.com > http://lists.xensource.com/xen-devel