xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: jerry <jerry.lilijun@huawei.com>
To: Wei Liu <wei.liu2@citrix.com>, stefano.stabellini@eu.citrix.com
Cc: xen-devel@lists.xen.org
Subject: netback BUG_ON when using copy_skb=1
Date: Wed, 16 Oct 2013 12:13:15 +0800	[thread overview]
Message-ID: <525E125B.80100@huawei.com> (raw)

Hi Wei Liu,

I am doing some network performance on Xen4.1.2 and kernel 3.0, and get a crash with BUG_ON(netbk->mmap_pages[idx] != page) in netbk_gop_frag() accidentally.

By analyzing the module drivers/xen/netback, I think the reason is as follows when sending packets from VM1 to VM2:
1) The two netback thread(the first for VM1 sending, second for VM2 receiving) run concurrently.
2) In first netback thread, it will do delayed copy from a foreign granted page to local memory when some outstanding packets have been pending too long( above half of one HZ).
   Then netbk->mmap_pages[idx] will be replaced with new allocated page.
3) If the packets are forwarded to VM2 by virtual switch, netbk_gop_frag() will be called in second netback thread.
   And that function will judge whether the pages in skb frags[] is foreign in order to make sure how to do grant copy.
4) If the page replacing was done after the page foreign judge in netbk_gop_frag(), the BUG will be invoked because the page from skb frags[] are different with mmap_pages[idx].

I tried to using spin_lock to protect the page accessing, but no appropriate solutions was found.
How to fix this problem?  Would you like to share some opinions?

In addition, I have tried to turn off copy_skb. Then the vif netdevice may not be released after shutting down VM,
that's because outstanding packets hold the reference count of the device too long for some unknown reason.
The reason may be that the NIC does not release packets after DMA.
Does anyone have met such problems? Thanks.

Best regards,
Jerry

             reply	other threads:[~2013-10-16  4:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16  4:13 jerry [this message]
2013-10-16 11:10 ` netback BUG_ON when using copy_skb=1 Jan Beulich
2013-10-17  7:41   ` jerry
2013-10-17  8:00     ` Jan Beulich
2013-10-17 10:26       ` jerry
2013-10-17 12:11         ` Jan Beulich
2013-10-22  1:18           ` jerry
2013-10-22  7:11             ` Jan Beulich
2013-10-26  8:32   ` jerry
2013-10-28  7:43     ` Jan Beulich
2013-10-29  4:04       ` jerry
2013-10-28 11:43     ` Wei Liu
2013-10-31 15:17       ` Ian Campbell
2013-10-31 15:32         ` Wei Liu
2013-11-01  2:53           ` jerry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=525E125B.80100@huawei.com \
    --to=jerry.lilijun@huawei.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).