[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

El 20/09/14 a les 12.57, Chentao(Boby) ha escrit:
> 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}
>     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.
>     What's your opinion of my modification? I am very looking forward to your 
> reply. Any reply is appreciated.


Yes, using grant-copy instead of grant-map is going to solve the
problem, but it also defeats the purpose of persistent grants. I'm
afraid it is going to introduce a noticeable performance penalty.

IMHO a better solution would be to use GNTTABOP_unmap_and_replace with
the scratch balloon page instead of GNTTABOP_unmap_grant_ref. See
arch/x86/xen/p2m.c m2p_remove_override for an example implementation of
this procedure.


Xen-devel mailing list



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