From: annie li <annie.li@oracle.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
David Vrabel <david.vrabel@citrix.com>,
Zoltan Kiss <zoltan.kiss@citrix.com>,
David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH net v5] xen-netback: fix fragment detection in checksum setup
Date: Thu, 05 Dec 2013 18:00:38 +0800 [thread overview]
Message-ID: <52A04EC6.1060606@oracle.com> (raw)
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD01A3C91@AMSPEX01CL01.citrite.net>
On 2013/12/5 17:08, Paul Durrant wrote:
>> -----Original Message-----
>> From: annie li [mailto:annie.li@oracle.com]
>> Sent: 05 December 2013 06:28
>> To: Paul Durrant
>> Cc: xen-devel@lists.xen.org; netdev@vger.kernel.org; Zoltan Kiss; Wei Liu;
>> Ian Campbell; David Vrabel; David Miller
>> Subject: Re: [PATCH net v5] xen-netback: fix fragment detection in checksum
>> setup
>>
>>
>> On 2013/12/4 1:39, Paul Durrant wrote:
>>
>>> +/* This value should be large enough to cover a tagged ethernet header
>> plus
>>> + * an IPv6 header, all options, and a maximal TCP or UDP header.
>>> + */
>>> +#define MAX_IPV6_HDR_LEN 256
>>> +
>>> +#define OPT_HDR(type, skb, off) \
>>> + (type *)(skb_network_header(skb) + (off))
>>> +
>>> static int checksum_setup_ipv6(struct xenvif *vif, struct sk_buff *skb,
>>> int recalculate_partial_csum)
>>> {
>>> - int err = -EPROTO;
>>> - struct ipv6hdr *ipv6h = (void *)skb->data;
>>> + int err;
>>> u8 nexthdr;
>>> - unsigned int header_size;
>>> unsigned int off;
>>> + unsigned int len;
>>> bool fragment;
>>> bool done;
>>>
>>> + fragment = false;
>>> done = false;
>>>
>>> off = sizeof(struct ipv6hdr);
>>>
>>> - header_size = skb->network_header + off;
>>> - maybe_pull_tail(skb, header_size);
>>> + err = maybe_pull_tail(skb, off, MAX_IPV6_HDR_LEN);
>>> + if (err < 0)
>>> + goto out;
>>>
>>> - nexthdr = ipv6h->nexthdr;
>>> + nexthdr = ipv6_hdr(skb)->nexthdr;
>>>
>>> - while ((off <= sizeof(struct ipv6hdr) + ntohs(ipv6h->payload_len))
>> &&
>>> - !done) {
>>> + len = sizeof(struct ipv6hdr) + ntohs(ipv6_hdr(skb)->payload_len);
>>> + while (off <= len && !done) {
>>> switch (nexthdr) {
>>> case IPPROTO_DSTOPTS:
>>> case IPPROTO_HOPOPTS:
>>> case IPPROTO_ROUTING: {
>>> - struct ipv6_opt_hdr *hp = (void *)(skb->data + off);
>>> + struct ipv6_opt_hdr *hp;
>>>
>>> - header_size = skb->network_header +
>>> - off +
>>> - sizeof(struct ipv6_opt_hdr);
>>> - maybe_pull_tail(skb, header_size);
>>> + err = maybe_pull_tail(skb,
>>> + off +
>>> + sizeof(struct ipv6_opt_hdr),
>>> + MAX_IPV6_HDR_LEN);
>>> + if (err < 0)
>>> + goto out;
>>>
>>> + hp = OPT_HDR(struct ipv6_opt_hdr, skb, off);
>>> nexthdr = hp->nexthdr;
>>> off += ipv6_optlen(hp);
>>> break;
>>> }
>>> case IPPROTO_AH: {
>>> - struct ip_auth_hdr *hp = (void *)(skb->data + off);
>>> + struct ip_auth_hdr *hp;
>>> +
>>> + err = maybe_pull_tail(skb,
>>> + off +
>>> + sizeof(struct ip_auth_hdr),
>>> + MAX_IPV6_HDR_LEN);
>>> + if (err < 0)
>>> + goto out;
>>> +
>>> + hp = OPT_HDR(struct ip_auth_hdr, skb, off);
>>> + nexthdr = hp->nexthdr;
>>> + off += ipv6_authlen(hp);
>>> + break;
>>> + }
>>> + case IPPROTO_FRAGMENT: {
>>> + struct frag_hdr *hp;
>>>
>>> - header_size = skb->network_header +
>>> - off +
>>> - sizeof(struct ip_auth_hdr);
>>> - maybe_pull_tail(skb, header_size);
>>> + err = maybe_pull_tail(skb,
>>> + off +
>>> + sizeof(struct frag_hdr),
>>> + MAX_IPV6_HDR_LEN);
>>> + if (err < 0)
>>> + goto out;
>>> +
>>> + hp = OPT_HDR(struct frag_hdr, skb, off);
>>> +
>>> + if (hp->frag_off & htons(IP6_OFFSET | IP6_MF))
>>> + fragment = true;
>>>
>>> nexthdr = hp->nexthdr;
>>> - off += (hp->hdrlen+2)<<2;
>>> + off += sizeof(struct frag_hdr);
>>> break;
>>> }
>>> - case IPPROTO_FRAGMENT:
>>> - fragment = true;
>>> - /* fall through */
>> About IPv6 extension headers, should "Encapsulating Security Payload" be
>> processed too?(See rfc2460 and rfc2406) Is there any concern to ignore
>> it here?
>>
> It's deliberately ignored. If we have an ESP header then the TCP/UDP header and payload will be encrypted so you can't do checksum offload, hence this function should return an error.
>
Got it. But from current code, if ESP extension header exists, switch
(nexthdr) will go into default case directly, and done is set with true,
then the code quits switch and while loop. After that, it will go into
next switch and then the default case since the nexthdr is ipv6 ESP
extension header, not TCP/UDP header. Then netdev_err probably prints
out improper log.
Thanks
Annie
next prev parent reply other threads:[~2013-12-05 10:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 17:39 [PATCH net v5] xen-netback: fix fragment detection in checksum setup Paul Durrant
2013-12-05 6:28 ` annie li
2013-12-05 9:08 ` Paul Durrant
2013-12-05 10:00 ` annie li [this message]
2013-12-05 10:45 ` [Xen-devel] " Paul Durrant
2013-12-05 13:11 ` annie li
2013-12-05 14:53 ` Wei Liu
2013-12-06 1:32 ` David Miller
2013-12-10 16:11 ` [Xen-devel] " Jan Beulich
2013-12-10 16:24 ` Paul Durrant
2013-12-10 16:58 ` Jan Beulich
2013-12-10 17:29 ` Paul Durrant
2013-12-11 7:27 ` Jan Beulich
2013-12-10 17:12 ` Eric Dumazet
2013-12-11 9:47 ` Ian Campbell
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=52A04EC6.1060606@oracle.com \
--to=annie.li@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=davem@davemloft.net \
--cc=david.vrabel@citrix.com \
--cc=netdev@vger.kernel.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=zoltan.kiss@citrix.com \
/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).