search for: fast_flush_area

I think you need this patch otherwise you will be passing uninitialised data from the stack to GNTTABOP_unmap_grant_ref in fast_flush_area. Also, I think the memset of the pending_grant_handles array should happen before you start using them so I moved it to before blkif_xenbus_init. I''m not sure if this is necessary or it might possibly have to go even earlier. Signed off by Harry Butterworth butterwo@uk.ibm.com. ______...

In dispatch_rw_block_io after a call to HYPERVISOR_grant_table_op, there is the following code which calls fast_flush_area and breaks out of the loop early if one of the handles returned from HYPERVISOR_grant_table_op is negative: for (i = 0; i < nseg; i++) { if (unlikely(map[i].handle < 0)) { DPRINTK("invalid buffer -- could not remap it\n"); fast_flush_area(pending_idx, nseg); goto bad_de...

...vma->vm_mm; + + down_write(&mm->mmap_sem); zap_page_range( info->vma, info->vma->vm_start, info->vma->vm_end - info->vma->vm_start, NULL); + up_write(&mm->mmap_sem); kfree(info->vma->vm_private_data); @@ -993,12 +997,13 @@ static void fast_flush_area(pending_req_ int tapidx) { struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST*2]; - unsigned int i, invcount = 0; + unsigned int i, invcount = 0, locked = 0; struct grant_handle_pair *khandle; uint64_t ptep; int ret, mmap_idx; unsigned long kvaddr, uvaddr; tap_b...

Patrick, there following patches fix xenpaging for me. Granttable handling is incomplete. If a page is gone, a GNTST_eagain should be returned to the caller to inidcate the hypercall has to be retried after a while, until the page is available again. Please review. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com