linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: <ian.campbell@citrix.com>, <xen-devel@lists.xenproject.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<jonathan.davies@citrix.com>
Subject: Re: [PATCH net-next v2 1/9] xen-netback: Introduce TX grant map definitions
Date: Mon, 16 Dec 2013 15:21:40 +0000	[thread overview]
Message-ID: <52AF1A84.3090304@citrix.com> (raw)
In-Reply-To: <20131213191423.GA12582@zion.uk.xensource.com>

On 13/12/13 19:14, Wei Liu wrote:
>>>> +	spin_lock_irqsave(&vif->dealloc_lock, flags);
>>>> > >>+	do {
>>>> > >>+		pending_idx = ubuf->desc;
>>>> > >>+		ubuf = (struct ubuf_info *) ubuf->ctx;
>>>> > >>+		index = pending_index(vif->dealloc_prod);
>>>> > >>+		vif->dealloc_ring[index] = pending_idx;
>>>> > >>+		/* Sync with xenvif_tx_action_dealloc:
>>>> > >>+		 * insert idx then incr producer.
>>>> > >>+		 */
>>>> > >>+		smp_wmb();
>>>> > >>+		vif->dealloc_prod++;
>>>> > >>+	} while (ubuf);
>>>> > >>+	wake_up(&vif->dealloc_wq);
>>>> > >>+	spin_unlock_irqrestore(&vif->dealloc_lock, flags);
> [...]
>>> > >
>>>> > >>+		smp_rmb();
>>>> > >>+
>>>> > >>+		while (dc != dp) {
>>>> > >>+			pending_idx =
>>>> > >>+				vif->dealloc_ring[pending_index(dc++)];
>>>> > >>+
>>>> > >>+			/* Already unmapped? */
>>>> > >>+			if (vif->grant_tx_handle[pending_idx] ==
>>>> > >>+				NETBACK_INVALID_HANDLE) {
>>>> > >>+				netdev_err(vif->dev,
>>>> > >>+					"Trying to unmap invalid handle! "
>>>> > >>+					"pending_idx: %x\n", pending_idx);
>>>> > >>+				continue;
>>>> > >>+			}
>>> > >
>>> > >Should this be BUG_ON? AIUI this kthread should be the only one doing
>>> > >unmap, right?
>> >The NAPI instance can do it as well if it is a small packet fits
>> >into PKT_PROT_LEN. But still this scenario shouldn't really happen,
>> >I was just not sure we have to crash immediately. Maybe handle it as
>> >a fatal error and destroy the vif?
>> >
> It depends. If this is within the trust boundary, i.e. everything at the
> stage should have been sanitized then we should BUG_ON because there's
> clearly a bug somewhere in the sanitization process, or in the
> interaction of various backend routines.

My understanding is that crashing should be avoided if we can bail out 
somehow. At this point there is clearly a bug in netback somewhere, 
something unmapped that page before it should have happened, or at least 
that array get corrupted somehow. However there is a chance that 
xenvif_fatal_tx_err() can contain the issue, and the rest of the system 
can go unaffected.

Zoli

  reply	other threads:[~2013-12-16 15:21 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12 23:48 [PATCH net-next v2 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy Zoltan Kiss
2013-12-12 23:48 ` [PATCH net-next v2 1/9] xen-netback: Introduce TX grant map definitions Zoltan Kiss
2013-12-13 15:31   ` Wei Liu
2013-12-13 18:22     ` Zoltan Kiss
2013-12-13 19:14       ` Wei Liu
2013-12-16 15:21         ` Zoltan Kiss [this message]
2013-12-16 17:50           ` Wei Liu
2014-01-07 14:50             ` Zoltan Kiss
2013-12-12 23:48 ` [PATCH net-next v2 2/9] xen-netback: Change TX path from grant copy to mapping Zoltan Kiss
2013-12-13 15:36   ` Wei Liu
2013-12-16 15:38     ` Zoltan Kiss
2013-12-16 18:21       ` Wei Liu
2013-12-16 18:57         ` Zoltan Kiss
2013-12-16 19:06           ` Wei Liu
2013-12-17 21:49   ` [Xen-devel] " Konrad Rzeszutek Wilk
2013-12-30 17:58     ` Zoltan Kiss
2013-12-12 23:48 ` [PATCH net-next v2 3/9] xen-netback: Remove old TX grant copy definitons and fix indentations Zoltan Kiss
2013-12-12 23:48 ` [PATCH net-next v2 4/9] xen-netback: Change RX path for mapped SKB fragments Zoltan Kiss
2013-12-12 23:48 ` [PATCH net-next v2 5/9] xen-netback: Add stat counters for zerocopy Zoltan Kiss
2013-12-12 23:48 ` [PATCH net-next v2 6/9] xen-netback: Handle guests with too many frags Zoltan Kiss
2013-12-13 15:43   ` Wei Liu
2013-12-16 16:10     ` Zoltan Kiss
2013-12-16 18:09       ` Wei Liu
2014-01-07 15:23         ` Zoltan Kiss
2013-12-12 23:48 ` [PATCH net-next v2 7/9] xen-netback: Add stat counters for frag_list skbs Zoltan Kiss
2013-12-12 23:48 ` [PATCH net-next v2 8/9] xen-netback: Timeout packets in RX path Zoltan Kiss
2013-12-13 15:44   ` Wei Liu
2013-12-16 17:16     ` Zoltan Kiss
2013-12-16 19:03       ` Wei Liu
2013-12-12 23:48 ` [PATCH net-next v2 9/9] xen-netback: Aggregate TX unmap operations Zoltan Kiss
2013-12-13 15:44   ` Wei Liu
2013-12-16 16:30     ` Zoltan Kiss
2013-12-16  6:32 ` [Xen-devel] [PATCH net-next v2 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy annie li
2013-12-16 16:13   ` Zoltan Kiss

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=52AF1A84.3090304@citrix.com \
    --to=zoltan.kiss@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jonathan.davies@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.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).