| Message ID | 56044031.5000303@gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
On Thu, Sep 24, 2015 at 11:25 AM, Thomas F Herbert <thomasfherbert@gmail.com> wrote: > Pravin, > > I am you hoping you can take a look at a potential problem with my kernel > module patch submitted to net-dev today. I decided to submit it anyway > because that is the best way to get eyes on it. > > I am still seeing a problem where the 4 conntrak attributes show up in an > upcall when a double tagged packet is received. The attribute lengths for > the 4 unknown attributes should be -1 but are showing up as odd lengths. I > can't see where my patch below is causing this problem but I don't see > similar errors with missed upcall in either single tagged or untagged > packets. I have applied my companion patch to the user space for 802.1ad so > the problem could be in that patch with de-serializing "unknown" attributes. > > Also, this may not be a problem at all because the kernel module includes > the conntrak patches but the user space does not as yet. > > I am running ovs commit ca92d173 with my user space 802.1ad patch. > > The error message is below: > > Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]: > recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad key > length 1, expected -1)(00),key23(bad key length 2, expected -1)(00 > 00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key length > 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8), > vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800), > ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0))) > I am not sure. can you send me github link to user-space patch, so that I can check.
On 9/24/15 7:43 PM, Pravin Shelar wrote: > On Thu, Sep 24, 2015 at 11:25 AM, Thomas F Herbert > <thomasfherbert@gmail.com> wrote: >> Pravin, >> >> I am you hoping you can take a look at a potential problem with my kernel >> module patch submitted to net-dev today. I decided to submit it anyway >> because that is the best way to get eyes on it. >> >> I am still seeing a problem where the 4 conntrak attributes show up in an >> upcall when a double tagged packet is received. The attribute lengths for >> the 4 unknown attributes should be -1 but are showing up as odd lengths. I >> can't see where my patch below is causing this problem but I don't see >> similar errors with missed upcall in either single tagged or untagged >> packets. I have applied my companion patch to the user space for 802.1ad so >> the problem could be in that patch with de-serializing "unknown" attributes. >> >> Also, this may not be a problem at all because the kernel module includes >> the conntrak patches but the user space does not as yet. >> >> I am running ovs commit ca92d173 with my user space 802.1ad patch. >> >> The error message is below: >> >> Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]: >> recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad key >> length 1, expected -1)(00),key23(bad key length 2, expected -1)(00 >> 00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key length >> 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8), >> vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800), >> ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0))) >> > > I am not sure. can you send me github link to user-space patch, so > that I can check. Pravin, OK, also I noticed that the user space patch for conntrak was submitted on 9/17. I think I will try to rebase user space patch on top of conntrak patch and re-test after fixing issues in kernel patch. Thanks, >
On 25 September 2015 at 05:10, Thomas F Herbert <thomasfherbert@gmail.com> wrote: > On 9/24/15 7:43 PM, Pravin Shelar wrote: >> >> On Thu, Sep 24, 2015 at 11:25 AM, Thomas F Herbert >> <thomasfherbert@gmail.com> wrote: >>> >>> Pravin, >>> >>> I am you hoping you can take a look at a potential problem with my kernel >>> module patch submitted to net-dev today. I decided to submit it anyway >>> because that is the best way to get eyes on it. >>> >>> I am still seeing a problem where the 4 conntrak attributes show up in an >>> upcall when a double tagged packet is received. The attribute lengths for >>> the 4 unknown attributes should be -1 but are showing up as odd lengths. >>> I >>> can't see where my patch below is causing this problem but I don't see >>> similar errors with missed upcall in either single tagged or untagged >>> packets. I have applied my companion patch to the user space for 802.1ad >>> so >>> the problem could be in that patch with de-serializing "unknown" >>> attributes. >>> >>> Also, this may not be a problem at all because the kernel module includes >>> the conntrak patches but the user space does not as yet. >>> >>> I am running ovs commit ca92d173 with my user space 802.1ad patch. >>> >>> The error message is below: >>> >>> Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]: >>> recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad >>> key >>> length 1, expected -1)(00),key23(bad key length 2, expected -1)(00 >>> 00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key >>> length >>> 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8), >>> >>> vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800), >>> >>> ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0))) >>> >> >> I am not sure. can you send me github link to user-space patch, so >> that I can check. > > Pravin, > > OK, also I noticed that the user space patch for conntrak was submitted on > 9/17. I think I will try to rebase user space patch on top of conntrak patch > and re-test after fixing issues in kernel patch. > > Thanks, Thomas, It looks like a mismatch between your kernel module headers and userspace headers. The conntrack changes upstream introduce four new KEY_ATTRs, but those haven't been backported to the userspace yet. So, if you add new KEY_ATTR numbers in $OVS_GIT/datapath/linux/compat/include/linux/openvswitch.h, then they may conflict with the numbers that the kernel uses in $LINUX_GIT/include/uapi/linux/openvswich. The kernel version is the source of truth for these. You're right, there was patches submitted for this recently and I'm actively working on trying to get those integrated into the OVS tree.
On 9/25/15 1:56 PM, Joe Stringer wrote: > On 25 September 2015 at 05:10, Thomas F Herbert > <thomasfherbert@gmail.com> wrote: >> On 9/24/15 7:43 PM, Pravin Shelar wrote: >>> On Thu, Sep 24, 2015 at 11:25 AM, Thomas F Herbert >>> <thomasfherbert@gmail.com> wrote: >>>> Pravin, >>>> >>>> I am you hoping you can take a look at a potential problem with my kernel >>>> module patch submitted to net-dev today. I decided to submit it anyway >>>> because that is the best way to get eyes on it. >>>> >>>> I am still seeing a problem where the 4 conntrak attributes show up in an >>>> upcall when a double tagged packet is received. The attribute lengths for >>>> the 4 unknown attributes should be -1 but are showing up as odd lengths. >>>> I >>>> can't see where my patch below is causing this problem but I don't see >>>> similar errors with missed upcall in either single tagged or untagged >>>> packets. I have applied my companion patch to the user space for 802.1ad >>>> so >>>> the problem could be in that patch with de-serializing "unknown" >>>> attributes. >>>> >>>> Also, this may not be a problem at all because the kernel module includes >>>> the conntrak patches but the user space does not as yet. >>>> >>>> I am running ovs commit ca92d173 with my user space 802.1ad patch. >>>> >>>> The error message is below: >>>> >>>> Sep 24 14:01:34 Centos7Bld ovs-vswitchd[2666]: >>>> recirc_id(0),dp_hash(0),skb_priority(0),in_port(3),skb_mark(0),key22(bad >>>> key >>>> length 1, expected -1)(00),key23(bad key length 2, expected -1)(00 >>>> 00),key24(bad key length 4, expected -1)(00 00 00 00),key25(bad key >>>> length >>>> 16, expected -1)(00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> 00),eth(src=52:f6:ef:24:b6:4e,dst=08:00:27:7f:8f:e1),eth_type(0x88a8), >>>> >>>> vlan(vid=100,pcp=0),encap(eth_type(0x8100),vlan(vid=999,pcp=0),encap(eth_type(0x0800), >>>> >>>> ipv4(src=192.168.1.3,dst=192.168.1.2,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0))) >>>> >>> I am not sure. can you send me github link to user-space patch, so >>> that I can check. >> Pravin, >> >> OK, also I noticed that the user space patch for conntrak was submitted on >> 9/17. I think I will try to rebase user space patch on top of conntrak patch >> and re-test after fixing issues in kernel patch. >> >> Thanks, > Thomas, > > It looks like a mismatch between your kernel module headers and > userspace headers. The conntrack changes upstream introduce four new > KEY_ATTRs, but those haven't been backported to the userspace yet. So, > if you add new KEY_ATTR numbers in > $OVS_GIT/datapath/linux/compat/include/linux/openvswitch.h, then they > may conflict with the numbers that the kernel uses in > $LINUX_GIT/include/uapi/linux/openvswich. The kernel version is the > source of truth for these. > > You're right, there was patches submitted for this recently and I'm > actively working on trying to get those integrated into the OVS tree. Yes, that is what I figured. Thanks, Joe. >
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c index c8db44a..db58e47 100644 --- a/net/openvswitch/flow.c +++ b/net/openvswitch/flow.c @@ -305,21 +305,77 @@ static bool icmp6hdr_ok(struct sk_buff *skb) static int parse_vlan(struct sk_buff *skb, struct sw_flow_key *key) { struct qtag_prefix { - __be16 eth_type; /* ETH_P_8021Q */ + __be16 eth_type; /* ETH_P_8021Q or ETH_P_8021AD */ __be16 tci; }; - struct qtag_prefix *qp; + struct qtag_prefix *qp = (struct qtag_prefix *)skb->data; - if (unlikely(skb->len < sizeof(struct qtag_prefix) + sizeof(__be16))) + struct qinqtag_prefix { + __be16 eth_type; /* ETH_P_8021Q or ETH_P_8021AD */ + __be16 tci; + __be16 inner_tpid; /* ETH_P_8021Q */ + __be16 ctci; + }; + + if (likely(skb_vlan_tag_present(skb))) { + key->eth.tci = htons(skb->vlan_tci); + + /* Case where upstream + * processing has already stripped the outer vlan tag. + */ + if (unlikely(skb->vlan_proto == htons(ETH_P_8021AD))) { + if (unlikely(skb->len < sizeof(struct qtag_prefix) + + sizeof(__be16))) { + key->eth.tci = 0; + return 0; + } + + if (unlikely(!pskb_may_pull(skb, + sizeof(struct qtag_prefix) + + sizeof(__be16)))) + return -ENOMEM; + + key->eth.cvlan.ctci = + qp->tci | htons(VLAN_TAG_PRESENT); + key->eth.cvlan.c_tpid = qp->eth_type; + + __skb_pull(skb, sizeof(struct qtag_prefix)); + } return 0; + } - if (unlikely(!pskb_may_pull(skb, sizeof(struct qtag_prefix) + - sizeof(__be16)))) - return -ENOMEM; - qp = (struct qtag_prefix *) skb->data; - key->eth.tci = qp->tci | htons(VLAN_TAG_PRESENT); - __skb_pull(skb, sizeof(struct qtag_prefix)); + if (qp->eth_type == htons(ETH_P_8021AD)) { + struct qinqtag_prefix *qinqp = + (struct qinqtag_prefix *)skb->data; + + if (unlikely(skb->len < sizeof(struct qinqtag_prefix) + + sizeof(__be16))) + return 0; + + if (unlikely(!pskb_may_pull(skb, sizeof(struct qinqtag_prefix) + + sizeof(__be16)))) + return -ENOMEM; + key->eth.tci = qinqp->tci | htons(VLAN_TAG_PRESENT); + key->eth.cvlan.ctci = qinqp->ctci | htons(VLAN_TAG_PRESENT); + key->eth.cvlan.c_tpid = qinqp->inner_tpid; + + __skb_pull(skb, sizeof(struct qinqtag_prefix)); + + return 0; + } + if (qp->eth_type == htons(ETH_P_8021Q)) { + if (unlikely(skb->len < sizeof(struct qtag_prefix) + + sizeof(__be16))) + return -ENOMEM; + + if (unlikely(!pskb_may_pull(skb, sizeof(struct qtag_prefix) + + sizeof(__be16)))) + return 0; + key->eth.tci = qp->tci | htons(VLAN_TAG_PRESENT); + + __skb_pull(skb, sizeof(struct qtag_prefix)); + } return 0; } @@ -481,11 +537,10 @@ static int key_extract(struct sk_buff *skb, struct sw_flow_key *key) */ key->eth.tci = 0; - if (skb_vlan_tag_present(skb)) - key->eth.tci = htons(skb->vlan_tci); - else if (eth->h_proto == htons(ETH_P_8021Q)) - if (unlikely(parse_vlan(skb, key))) - return -ENOMEM; + key->eth.cvlan.ctci = 0; + key->eth.cvlan.c_tpid = 0; + if (unlikely(parse_vlan(skb, key))) + return -ENOMEM; key->eth.type = parse_ethertype(skb); if (unlikely(key->eth.type == htons(0))) diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h index fe527d2..2c491e8 100644 --- a/net/openvswitch/flow.h +++ b/net/openvswitch/flow.h @@ -69,6 +69,11 @@ struct sw_flow_key { u8 src[ETH_ALEN]; /* Ethernet source address. */ u8 dst[ETH_ALEN]; /* Ethernet destination address. */ __be16 tci; /* 0 if no VLAN, VLAN_TAG_PRESENT set otherwise. */ + struct { + __be16 c_tpid; /* Vlan DL_type 802.1q or 802.1ad */ + __be16 ctci; /* 0 if no CVLAN, VLAN_TAG_PRESENT */ + /* set otherwise. */ + } cvlan; __be16 type; /* Ethernet frame type. */ } eth; union { diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c index c92d6a2..5fe415d 100644 --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -811,6 +811,27 @@ static int metadata_from_nlattrs(struct net *net, struct sw_flow_match *match, return 0; } +static int cust_vlan_from_nlattrs(struct sw_flow_match *match, + const struct nlattr *a[], + bool is_mask, bool log) +{ + __be16 ctci = 0; + __be16 c_tpid = 0; + + ctci = nla_get_be16(a[OVS_KEY_ATTR_VLAN]); + if (!(ctci & htons(VLAN_TAG_PRESENT))) { + if (is_mask) + OVS_NLERR(log, "VLAN CTCI mask does not have exact match for VLAN_TAG_PRESENT bit."); + else + OVS_NLERR(log, "VLAN CTCI does not have VLAN_TAG_PRESENT bit set."); + return -EINVAL; + } + c_tpid = nla_get_be16(a[OVS_KEY_ATTR_ETHERTYPE]); + SW_FLOW_KEY_PUT(match, eth.cvlan.c_tpid, c_tpid, is_mask); + SW_FLOW_KEY_PUT(match, eth.cvlan.ctci, ctci, is_mask); + return 0; +} + static int ovs_key_from_nlattrs(struct net *net, struct sw_flow_match