[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH 09/11] gnttab: avoid spurious maptrack handle allocation failures
When no memory is available in the hypervisor, rather than immediately failing the request try to steal a handle from another vCPU. Reported-by: George Dunlap <george.dunlap@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -397,7 +397,7 @@ get_maptrack_handle( struct vcpu *curr = current; unsigned int i, head; grant_handle_t handle; - struct grant_mapping *new_mt; + struct grant_mapping *new_mt = NULL; handle = __get_maptrack_handle(lgt, curr); if ( likely(handle != -1) ) @@ -408,8 +408,13 @@ get_maptrack_handle( /* * If we've run out of frames, try stealing an entry from another * VCPU (in case the guest isn't mapping across its VCPUs evenly). + * Also use this path in case we're out of memory, to avoid spurious + * failures. */ - if ( nr_maptrack_frames(lgt) >= max_maptrack_frames ) + if ( nr_maptrack_frames(lgt) < max_maptrack_frames ) + new_mt = alloc_xenheap_page(); + + if ( !new_mt ) { /* * Can drop the lock since no other VCPU can be adding a new @@ -432,12 +437,6 @@ get_maptrack_handle( return steal_maptrack_handle(lgt, curr); } - new_mt = alloc_xenheap_page(); - if ( !new_mt ) - { - spin_unlock(&lgt->maptrack_lock); - return -1; - } clear_page(new_mt); /* Attachment:
gnttab-spurious-mt-handle-fail.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |