From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/5] x86: properly propagate errors to hypercall callee Date: Fri, 11 Mar 2011 12:33:27 +0000 Message-ID: References: <4D7A0B120200007800035CB4@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D7A0B120200007800035CB4@vpn.id2.novell.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: Jan Beulich Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 11/03/2011 10:44, "Jan Beulich" wrote: > ioremap() in general can fail, but failure of the writing the page > table entries gets propagated to the caller only on the legacy > kernels iirc (due to the lack of a return value of the accessor for > pv-ops). > > The problem at hand, however, is with the vm_insert_...() > functions, which use set_pte_at(), which again has no return > value, so it'll need to be the accessors themselves to > > (a) never utilize the writeable page tables feature on any path > that can alter cache attributes, and > > (b) handle -ENOMEM from HYPERVISOR_update_va_mapping() > and HYPERVISOR_mmu_update() (without knowing much about > the context they're being called in). I can't see changes like that getting upstream. Maybe okay if you're prepared to carry the patch. Also I guess some callers may have trouble handling the error no matter how far you punt it up the call chain. -- Keir