From: Greg Rose <gvrose8192-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Darrell Ball <dball-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>,
"netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: "dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org"
<dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org>
Subject: Re: [PATCH] datapath: Fix for force/commit action failures
Date: Thu, 13 Jul 2017 10:12:15 -0700 [thread overview]
Message-ID: <174ca16b-264f-66ac-af0d-eec003cbcd07@gmail.com> (raw)
In-Reply-To: <76FBD265-9CC9-4366-A075-203E76BA4E97-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
On 07/13/2017 10:08 AM, Darrell Ball wrote:
>
>
> On 7/13/17, 9:25 AM, "ovs-dev-bounces-yBygre7rU0TnMu66kgdUjQ@public.gmane.org on behalf of Greg Rose" <ovs-dev-bounces-yBygre7rU0TnMu66kgdUjQ@public.gmane.org on behalf of gvrose8192-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> When there is an established connection in direction A->B, it is
> possible to receive a packet on port B which then executes
> ct(commit,force) without first performing ct() - ie, a lookup.
> In this case, we would expect that this packet can delete the existing
> entry so that we can commit a connection with direction B->A. However,
> currently we only perform a check in skb_nfct_cached() for whether
> OVS_CS_F_TRACKED is set and OVS_CS_F_INVALID is not set, ie that a
> lookup previously occurred. In the above scenario, a lookup has not
> occurred but we should still be able to statelessly look up the
> existing entry and potentially delete the entry if it is in the
> opposite direction.
>
> This patch extends the check to also hint that if the action has the
> force flag set, then we will lookup the existing entry so that the
> force check at the end of skb_nfct_cached has the ability to delete
> the connection.
>
> CC: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
> CC: Pravin Shalar <pshelar-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Joe Stringer <joe-LZ6Gd1LRuIk@public.gmane.org>
> Signed-off-by: Greg Rose <gvrose8192-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> net/openvswitch/conntrack.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> index 08679eb..9041cf8 100644
> --- a/net/openvswitch/conntrack.c
> +++ b/net/openvswitch/conntrack.c
> @@ -641,17 +641,21 @@ static bool skb_nfct_cached(struct net *net,
> ct = nf_ct_get(skb, &ctinfo);
> /* If no ct, check if we have evidence that an existing conntrack entry
> * might be found for this skb. This happens when we lose a skb->_nfct
> - * due to an upcall. If the connection was not confirmed, it is not
> - * cached and needs to be run through conntrack again.
> + * due to an upcall, or if the direction is being forced. If the
> + * connection was not confirmed, it is not cached and needs to be run
> + * through conntrack again.
> */
> - if (!ct && key->ct_state & OVS_CS_F_TRACKED &&
> + if ((!ct && (key->ct_state & OVS_CS_F_TRACKED) &&
> !(key->ct_state & OVS_CS_F_INVALID) &&
> - key->ct_zone == info->zone.id) {
> + key->ct_zone == info->zone.id) ||
> + (!key->ct_state && info->force)) {
> ct = ovs_ct_find_existing(net, &info->zone, info->family, skb,
> !!(key->ct_state
> & OVS_CS_F_NAT_MASK));
> if (ct)
> nf_ct_get(skb, &ctinfo);
> + else
> + return false;
>
> the above else case looks redundant since it maps to the following check
> if (!ct)
> return false;
> which services a superset of the code flow.
Sure, we can let it fall through... missed that.
After waiting for more review I'll send a V2 patch.
Thanks for the review Darrell
- Greg
>
> }
> if (!ct)
> return false;
> --
> 1.8.3.1
>
> _______________________________________________
> dev mailing list
> dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=5da6ykiSQJBoJXmpq6iVknmPAc5JDzlVngmp8j_xcXA&s=PsX-njQ_hFqy8P77KNEyX0i7u165p2Wrbg4uAYqfbGs&e=
>
>
next prev parent reply other threads:[~2017-07-13 17:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-13 16:25 [PATCH] datapath: Fix for force/commit action failures Greg Rose
2017-07-13 17:08 ` [ovs-dev] " Darrell Ball
[not found] ` <76FBD265-9CC9-4366-A075-203E76BA4E97-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2017-07-13 17:12 ` Greg Rose [this message]
2017-07-13 17:46 ` Joe Stringer
2017-07-13 18:01 ` Greg Rose
[not found] ` <4a063b92-1e36-db6f-d6cc-4f215637f549-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-07-13 18:03 ` Joe Stringer
2017-07-13 22:38 ` Greg Rose
2017-07-13 23:08 ` Joe Stringer
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=174ca16b-264f-66ac-af0d-eec003cbcd07@gmail.com \
--to=gvrose8192-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=dball-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org \
--cc=dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 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).