All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: <netdev@vger.kernel.org>, Juergen Gross <jgross@suse.com>,
	Patrick Talbert <ptalbert@redhat.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary
Date: Fri, 09 Sep 2016 15:39:33 +0200	[thread overview]
Message-ID: <87y431qjje.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <87wpizamxv.fsf@vitty.brq.redhat.com> (Vitaly Kuznetsov's message of "Mon, 29 Aug 2016 12:28:44 +0200")

Vitaly Kuznetsov <vkuznets@redhat.com> writes:

> Vitaly Kuznetsov <vkuznets@redhat.com> writes:
>
>> David Vrabel <david.vrabel@citrix.com> writes:
>>
>>> On 22/08/16 16:42, Vitaly Kuznetsov wrote:
>>>> 
>>>> I see two ways to fix the issue:
>>>> - Change the 'wire' protocol between netfront and netback to start keeping
>>>>   the original SKB structure. We'll have to add a flag indicating the fact
>>>>   that the particular request is a part of the original linear part and not
>>>>   a frag. We'll need to know the length of the linear part to pre-allocate
>>>>   memory.
>>>
>>> I don't think there needs to be a protocol change.  I think the check in
>>> netback is bogus -- it's the total packet length that must be >
>>> HLEN_ETH.  The upper layers will pull any headers from the frags as
>>> needed
>>
>> I'm afraid this is not always true, just removing the check leads us to
>> the following:
>>
>> [  495.442186] kernel BUG at ./include/linux/skbuff.h:1927! 
>> [  495.468789] invalid opcode: 0000 [#1] SMP 
>
> What I wanted to say here is that this test makes me think the
> description of the patch I suggested is correct: an SKB can't have its
> linear part shorter than ETH_HLEN as the header is being pointed directly,
> upper network layers don't assemble it from frags, the check in netback
> is valid.
>
> So, how can we proceed here?

Sorry for the second ping but I'd really like to see this moving
forward...

-- 
  Vitaly

  parent reply	other threads:[~2016-09-09 13:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-22 15:42 [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary Vitaly Kuznetsov
2016-08-22 16:55 ` David Vrabel
2016-08-22 16:55 ` [Xen-devel] " David Vrabel
2016-08-23 18:51   ` Vitaly Kuznetsov
2016-08-23 18:51     ` Vitaly Kuznetsov
2016-08-29 10:28     ` Vitaly Kuznetsov
2016-08-29 10:28     ` [Xen-devel] " Vitaly Kuznetsov
2016-09-09 13:39       ` Vitaly Kuznetsov
2016-09-09 13:39       ` Vitaly Kuznetsov [this message]
2016-09-09 13:41 ` David Vrabel
2016-09-12 11:52   ` Vitaly Kuznetsov
2016-09-12 11:52   ` Vitaly Kuznetsov
2016-09-09 13:41 ` David Vrabel

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=87y431qjje.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ptalbert@redhat.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.