All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH net-next] xen-netfront: Add support for IPv6 offloads
Date: Thu, 7 Nov 2013 11:49:42 +0000	[thread overview]
Message-ID: <1383824982.32399.4.camel@kazak.uk.xensource.com> (raw)
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD0169E68@AMSPEX01CL01.citrite.net>

On Thu, 2013-11-07 at 11:02 +0000, Paul Durrant wrote:

> > (I found it confusing because you reset it in the recalculate_partial
> > rather than extending it which is what I expected)
> > 
> > maybe_pull_tail doesn't guarantee to pull up to the length of the given
> > parameter, e.g. if it is more then skb->len. Which I think means you
> > need some other explicit skb len checks around the place, don't you?
> > Otherwise you risk running past the end of the skb for a malformed
> > frame.
> > 
> 
> Yes, that's true. Probably best to have maybe_pull_tail() return a
> failure if it doesn't managed to pullup the requested amount then.

That would work.

> > Is it a requirement of the protocol that the list of IPPROTO_* we handle
> > must be followed by some other header? Do we really care or is it more
> > the upper stacks problem? Presumably it can get similarly malformed
> > packets off the wire?
> 
> I'd have to check but I'm pretty sure none of the protos we handle can
> be terminating so if done is not set then the packet is malformed.

OK. I'm not sure this is "our" problem though. we could just silently
throw this corrupt frame up at the stack without trying to redo the
checksum. Isn't that what would happen with real hardware?

> > > +		goto out;
> > > +	}
> > > +
> > > +	if (fragment) {
> > > +		if (net_ratelimit())
> > > +			pr_err("Packet is a fragment!\n");
> > 
> > Is that a bad thing?
> > 
> 
> Well, you can't do TCP or UDP checksum offload on a fragment, can you?

I guess I meant (as above), why do we particularly care? We could just
throw it at the stack, who will account it as a RX error and carry on

> > Speaking of which can checksum_setup_* be shared with netfront
> > somehow?
> > Or maybe even put in common code? (Perhaps as a future cleanup)
> > 
> 
> I think it really should be in common code, but I think that would be
> better handled as a separate patch to remove the duplication.

I'm ok with that. (I'm not netfront maintainer though...)

> Thanks for the comprehensive review!

No problem!

  reply	other threads:[~2013-11-07 11:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 11:59 [PATCH net-next] xen-netfront: Add support for IPv6 offloads Paul Durrant
2013-11-07 10:48 ` Ian Campbell
2013-11-07 11:02   ` Paul Durrant
2013-11-07 11:49     ` Ian Campbell [this message]
2013-11-15 11:19     ` Paul Durrant
2013-11-19 10:28       ` Ian Campbell
2013-11-19 11:24         ` Paul Durrant
2014-01-15 15:18 [PATCH net-next] xen-netfront: add " Paul Durrant
2014-01-15 15:25 ` [Xen-devel] " Andrew Cooper
2014-01-15 15:54   ` Paul Durrant
2014-01-15 15:54   ` [Xen-devel] " Paul Durrant
2014-01-15 16:03     ` Jan Beulich
2014-01-15 17:08       ` Paul Durrant
2014-01-15 16:03     ` Jan Beulich
2014-01-15 15:25 ` Andrew Cooper
2014-01-15 15:18 Paul Durrant

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=1383824982.32399.4.camel@kazak.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@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 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.