netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@corigine.com>
To: edward.cree@amd.com
Cc: linux-net-drivers@amd.com, davem@davemloft.net, kuba@kernel.org,
	pabeni@redhat.com, edumazet@google.com,
	Edward Cree <ecree.xilinx@gmail.com>,
	netdev@vger.kernel.org, habetsm.xilinx@gmail.com
Subject: Re: [PATCH v2 net-next 3/4] sfc: support TC decap rules matching on enc_ip_tos
Date: Fri, 12 May 2023 11:51:33 +0200	[thread overview]
Message-ID: <ZF4MJaY8/3bC4G5e@corigine.com> (raw)
In-Reply-To: <acc9f66562f7a82b2b033bc3ee3470e580036b81.1683834261.git.ecree.xilinx@gmail.com>

On Thu, May 11, 2023 at 08:47:30PM +0100, edward.cree@amd.com wrote:
> From: Edward Cree <ecree.xilinx@gmail.com>
> 
> Allow efx_tc_encap_match entries to include an ip_tos and ip_tos_mask.
> To avoid partially-overlapping Outer Rules (which can lead to undefined
>  behaviour in the hardware), store extra "pseudo" entries in our
>  encap_match hashtable, which are used to enforce that all Outer Rule
>  entries within a given <src_ip,dst_ip,udp_dport> tuple (or IPv6
>  equivalent) have the same ip_tos_mask.
> The "direct" encap_match entry takes a reference on the "pseudo",
>  allowing it to be destroyed when all "direct" entries using it are
>  removed.
> efx_tc_em_pseudo_type is an enum rather than just a bool because in
>  future an additional pseudo-type will be added to support Conntrack
>  offload.
> 
> Signed-off-by: Edward Cree <ecree.xilinx@gmail.com>

...

> @@ -425,12 +469,56 @@ static int efx_tc_flower_record_encap_match(struct efx_nic *efx,
>  #endif
>  	encap->udp_dport = match->value.enc_dport;
>  	encap->tun_type = type;
> +	encap->ip_tos = match->value.enc_ip_tos;
> +	encap->ip_tos_mask = match->mask.enc_ip_tos;
> +	encap->child_ip_tos_mask = child_ip_tos_mask;
> +	encap->type = em_type;
> +	encap->pseudo = pseudo;
>  	old = rhashtable_lookup_get_insert_fast(&efx->tc->encap_match_ht,
>  						&encap->linkage,
>  						efx_tc_encap_match_ht_params);
>  	if (old) {
>  		/* don't need our new entry */
>  		kfree(encap);

Hi Ed,

encap is freed here.

> +		if (pseudo) /* don't need our new pseudo either */
> +			efx_tc_flower_release_encap_match(efx, pseudo);
> +		/* check old and new em_types are compatible */
> +		switch (old->type) {
> +		case EFX_TC_EM_DIRECT:
> +			/* old EM is in hardware, so mustn't overlap with a
> +			 * pseudo, but may be shared with another direct EM
> +			 */
> +			if (em_type == EFX_TC_EM_DIRECT)
> +				break;
> +			NL_SET_ERR_MSG_MOD(extack, "Pseudo encap match conflicts with existing direct entry");
> +			return -EEXIST;
> +		case EFX_TC_EM_PSEUDO_MASK:
> +			/* old EM is protecting a ToS-qualified filter, so may
> +			 * only be shared with another pseudo for the same
> +			 * ToS mask.
> +			 */
> +			if (em_type != EFX_TC_EM_PSEUDO_MASK) {
> +				NL_SET_ERR_MSG_FMT_MOD(extack,
> +						       "%s encap match conflicts with existing pseudo(MASK) entry",
> +						       encap->type ? "Pseudo" : "Direct");

But dereferenced here.

> +				return -EEXIST;
> +			}
> +			if (child_ip_tos_mask != old->child_ip_tos_mask) {
> +				NL_SET_ERR_MSG_FMT_MOD(extack,
> +						       "Pseudo encap match for TOS mask %#04x conflicts with existing pseudo(MASK) entry for TOS mask %#04x",
> +						       child_ip_tos_mask,
> +						       old->child_ip_tos_mask);
> +				return -EEXIST;
> +			}
> +			break;
> +		default: /* Unrecognised pseudo-type.  Just say no */
> +			NL_SET_ERR_MSG_FMT_MOD(extack,
> +					       "%s encap match conflicts with existing pseudo(%d) entry",
> +					       encap->type ? "Pseudo" : "Direct",

And here.

> +					       old->type);
> +			return -EEXIST;
> +		}
> +		/* check old and new tun_types are compatible */
>  		if (old->tun_type != type) {
>  			NL_SET_ERR_MSG_FMT_MOD(extack,
>  					       "Egress encap match with conflicting tun_type %u != %u",

...

  reply	other threads:[~2023-05-12  9:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 19:47 [PATCH v2 net-next 0/4] sfc: more flexible encap matches on TC decap rules edward.cree
2023-05-11 19:47 ` [PATCH v2 net-next 1/4] sfc: release encap match in efx_tc_flow_free() edward.cree
2023-05-11 19:47 ` [PATCH v2 net-next 2/4] sfc: populate enc_ip_tos matches in MAE outer rules edward.cree
2023-05-11 19:47 ` [PATCH v2 net-next 3/4] sfc: support TC decap rules matching on enc_ip_tos edward.cree
2023-05-12  9:51   ` Simon Horman [this message]
2023-05-12 14:27     ` Edward Cree
2023-05-11 19:47 ` [PATCH v2 net-next 4/4] sfc: support TC decap rules matching on enc_src_port edward.cree
2023-05-12 11:50 ` [PATCH v2 net-next 0/4] sfc: more flexible encap matches on TC decap rules patchwork-bot+netdevbpf

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=ZF4MJaY8/3bC4G5e@corigine.com \
    --to=simon.horman@corigine.com \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=edumazet@google.com \
    --cc=edward.cree@amd.com \
    --cc=habetsm.xilinx@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-net-drivers@amd.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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).