[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.