Re: [Xen-devel] xen-blkback unmap with network retansmission will cause a coredump

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 20/09/14 11:57, Chentao(Boby) wrote:
> Hi konrad and roger,
> 
> When xen-blkback module executes unmap operation, and at the same 
> time the skb of network retansmission uses this map page, it will 
> cause a crash of hostos.
> 
> The crash stack of this problem is like below. 
> <ffffffff8041133e>{do_page_fault+0x38e} 
> <ffffffff8040d9e8>{page_fault+0x28} <ffffffff80223cdb>{memcpy+0xb} 
> <ffffffff802325c2>{swiotlb_tbl_map_single+0x212} 
> <ffffffff8023274a>{swiotlb_map_page+0x17a} 
> <ffffffffa03468e6>{tg3:tg3_start_xmit+0x656} 
> <ffffffff80354d14>{dev_hard_start_xmit+0x334} 
> <ffffffff803721be>{sch_direct_xmit+0x1ae}

What dom0 (backend) kernel are you using?  Which backend and what storage?

> I search website, found citrix engineers has met this problem long
> time ago. And I realized citrix engineers solve this problem
> according to modify kernel stack. Because this modification is very
> large, linux kernel community hasn't accept it until now. I have a
> immature thought, in dispatch_rw_block_io function, if this io is a
> write operation, we use grant copy hypercall instead of grant map
> hypercall. I verify my modification and it can solve this problem.

Switching to grant copy will reduce performance significantly in many cases.

This was fixed for user space backends by replacing the foreign mapping
with a mapping of a scratch page, when unmapping the grant.

Something similar should be done for kernel-only foreign mappings.  This
requires a GNTOP_unmap_and_duplicate hypercall sub-op to allow efficient
batching.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel