All of lore.kernel.org
 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: Tue, 7 Jan 2014 14:50:59 +0000	[thread overview]
Message-ID: <52CC1453.3090804@citrix.com> (raw)
In-Reply-To: <20131216175036.GB25969@zion.uk.xensource.com>

On 16/12/13 17:50, Wei Liu wrote:
> On Mon, Dec 16, 2013 at 03:21:40PM +0000, Zoltan Kiss wrote:
> [...]
>>>>>>>
>>>>>>> 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.
>>
>
> That would make debugging much harder if a crash is caused by a previous
> corrupted array and we pretend we can carry on serving IMHO. Now netback
> is having three routines (NAPI, two kthreads) to serve a single vif, the
> interation among them makes bug hard to reproduce.

OK, I'll make this a BUG() in the next series.

Zoli


  parent reply	other threads:[~2014-01-07 14:51 UTC|newest]

Thread overview: 67+ 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 15:31   ` Wei Liu
2013-12-13 18:22     ` Zoltan Kiss
2013-12-13 18:22     ` Zoltan Kiss
2013-12-13 19:14       ` Wei Liu
2013-12-13 19:14       ` Wei Liu
2013-12-16 15:21         ` Zoltan Kiss
2013-12-16 15:21         ` Zoltan Kiss
2013-12-16 17:50           ` Wei Liu
2014-01-07 14:50             ` Zoltan Kiss
2014-01-07 14:50             ` Zoltan Kiss [this message]
2013-12-16 17:50           ` Wei Liu
2013-12-12 23:48 ` 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-12 23:48   ` Zoltan Kiss
2013-12-13 15:36   ` Wei Liu
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-16 19:06           ` Wei Liu
2013-12-16 18:57         ` Zoltan Kiss
2013-12-16 18:21       ` Wei Liu
2013-12-16 15:38     ` Zoltan Kiss
2013-12-17 21:49   ` [Xen-devel] " Konrad Rzeszutek Wilk
2013-12-30 17:58     ` Zoltan Kiss
2013-12-30 17:58     ` [Xen-devel] " Zoltan Kiss
2013-12-17 21:49   ` Konrad Rzeszutek Wilk
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   ` 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 ` 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 ` 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-12 23:48 ` Zoltan Kiss
2013-12-13 15:43   ` Wei Liu
2013-12-13 15:43   ` Wei Liu
2013-12-16 16:10     ` Zoltan Kiss
2013-12-16 16:10     ` Zoltan Kiss
2013-12-16 18:09       ` Wei Liu
2014-01-07 15:23         ` Zoltan Kiss
2014-01-07 15:23         ` Zoltan Kiss
2013-12-16 18:09       ` Wei Liu
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 ` 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-16 19:03       ` Wei Liu
2013-12-16 17:16     ` Zoltan Kiss
2013-12-13 15:44   ` Wei Liu
2013-12-12 23:48 ` Zoltan Kiss
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-13 15:44   ` Wei Liu
2013-12-16 16:30     ` Zoltan Kiss
2013-12-16 16:30     ` Zoltan Kiss
2013-12-12 23:48 ` Zoltan Kiss
2013-12-16  6:32 ` [PATCH net-next v2 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy annie li
2013-12-16  6:32 ` [Xen-devel] " annie li
2013-12-16 16:13   ` Zoltan Kiss
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=52CC1453.3090804@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.