All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Tom Herbert <tom@herbertland.com>
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
	netdev@vger.kernel.org, felipe@sipanda.io,
	willemdebruijn.kernel@gmail.com, pablo@netfilter.org,
	laforge@gnumonks.org, xeb@mail.ru
Subject: Re: [PATCH net-next v4 05/13] flow_dissector: UDP encap infrastructure
Date: Sat, 24 Aug 2024 20:18:19 +0100	[thread overview]
Message-ID: <20240824191819.GU2164@kernel.org> (raw)
In-Reply-To: <20240823201557.1794985-6-tom@herbertland.com>

On Fri, Aug 23, 2024 at 01:15:49PM -0700, Tom Herbert wrote:
> Add infrastructure for parsing into UDP encapsulations
> 
> Add function __skb_flow_dissect_udp that is called for IPPROTO_UDP.
> The flag FLOW_DISSECTOR_F_PARSE_UDP_ENCAPS enables parsing of UDP
> encapsulations. If the flag is set when parsing a UDP packet then
> a socket lookup is performed. The offset of the base network header,
> either an IPv4 or IPv6 header, is tracked and passed to
> __skb_flow_dissect_udp so that it can perform the socket lookup
> 
> If a socket is found and it's for a UDP encapsulation (encap_type is
> set in the UDP socket) then a switch is performed on the encap_type
> value (cases are UDP_ENCAP_* values)
> 
> An encapsulated packet in UDP can either be indicated by an
> EtherType or IP protocol. The processing for dissecting a UDP encap
> protocol returns a flow dissector return code. If
> FLOW_DISSECT_RET_PROTO_AGAIN or FLOW_DISSECT_RET_IPPROTO_AGAIN is
> returned then the corresponding  encapsulated protocol is dissected.
> The nhoff is set to point to the header to process.  In the case
> FLOW_DISSECT_RET_PROTO_AGAIN the EtherType protocol is returned and
> the IP protocol is set to zero. In the case of
> FLOW_DISSECT_RET_IPPROTO_AGAIN, the IP protocol is returned and
> the EtherType protocol is returned unchanged
> 
> Signed-off-by: Tom Herbert <tom@herbertland.com>

...

> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c

...

> @@ -806,6 +807,134 @@ __skb_flow_dissect_batadv(const struct sk_buff *skb,
>  	return FLOW_DISSECT_RET_PROTO_AGAIN;
>  }
>  
> +static enum flow_dissect_ret
> +__skb_flow_dissect_udp(const struct sk_buff *skb, const struct net *net,
> +		       struct flow_dissector *flow_dissector,
> +		       void *target_container, const void *data,
> +		       int *p_nhoff, int hlen, __be16 *p_proto,
> +		       u8 *p_ip_proto, int base_nhoff, unsigned int flags,
> +		       unsigned int num_hdrs)
> +{
> +	enum flow_dissect_ret ret;
> +	struct udphdr _udph;
> +	int nhoff;
> +
> +	if (!(flags & FLOW_DISSECTOR_F_PARSE_UDP_ENCAPS))
> +		return FLOW_DISSECT_RET_OUT_GOOD;
> +
> +	/* Check that the netns for the skb device is the same as the caller's,
> +	 * and only dissect UDP if we haven't yet encountered any encapsulation.
> +	 * The goal is to ensure that the socket lookup is being done in the
> +	 * right netns. Encapsulations may push packets into different name
> +	 * spaces, so this scheme is restricting UDP dissection to cases where
> +	 * they are in the same name spaces or at least the original name space.
> +	 * This should capture the majority of use cases for UDP encaps, and
> +	 * if we do encounter a UDP encapsulation within a different namespace
> +	 * then the only effect is we don't attempt UDP dissection
> +	 */
> +	if (dev_net(skb->dev) != net || num_hdrs > 0)
> +		return FLOW_DISSECT_RET_OUT_GOOD;
> +
> +	switch (*p_proto) {
> +#ifdef CONFIG_INET
> +	case htons(ETH_P_IP): {
> +		const struct udphdr *udph;
> +		const struct iphdr *iph;
> +		struct iphdr _iph;
> +		struct sock *sk;
> +
> +		iph = __skb_header_pointer(skb, base_nhoff, sizeof(_iph), data,
> +					   hlen, &_iph);
> +		if (!iph)
> +			return FLOW_DISSECT_RET_OUT_BAD;
> +
> +		udph = __skb_header_pointer(skb, *p_nhoff, sizeof(_udph), data,
> +					    hlen, &_udph);
> +		if (!udph)
> +			return FLOW_DISSECT_RET_OUT_BAD;
> +
> +		rcu_read_lock();
> +		/* Look up the UDPv4 socket and get the encap_type */
> +		sk = __udp4_lib_lookup(net, iph->saddr, udph->source,
> +				       iph->daddr, udph->dest,
> +				       inet_iif(skb), inet_sdif(skb),
> +				       net->ipv4.udp_table, NULL);
> +		if (!sk || !udp_sk(sk)->encap_type) {
> +			rcu_read_unlock();
> +			return FLOW_DISSECT_RET_OUT_GOOD;
> +		}
> +
> +		encap_type = udp_sk(sk)->encap_type;

Hi Tom,

I guess a local change went astray, or something like that,
because encap_type isn't declared in this scope.

> +		rcu_read_unlock();
> +
> +		break;
> +	}

...

-- 
pw-bot: cr

  reply	other threads:[~2024-08-24 19:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-23 20:15 [PATCH net-next v4 00/13] flow_dissector: Dissect UDP encapsulation protocols Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 01/13] ipv6: Add udp6_lib_lookup to IPv6 stubs Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 02/13] flow_dissector: Parse ETH_P_TEB and move out of GRE Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 03/13] udp_encaps: Add new UDP_ENCAP constants Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 04/13] udp_encaps: Set proper UDP_ENCAP types in tunnel setup Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 05/13] flow_dissector: UDP encap infrastructure Tom Herbert
2024-08-24 19:18   ` Simon Horman [this message]
2024-08-23 20:15 ` [PATCH net-next v4 06/13] flow_dissector: Parse vxlan in UDP Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 07/13] flow_dissector: Parse foo-over-udp (FOU) Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 08/13] flow_dissector: Parse ESP, L2TP, and SCTP in UDP Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 09/13] flow_dissector: Parse Geneve " Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 10/13] flow_dissector: Parse GUE " Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 11/13] gtp: Move gtp_parse_exthdrs into net/gtp.h Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 12/13] flow_dissector: Parse gtp in UDP Tom Herbert
2024-08-23 20:15 ` [PATCH net-next v4 13/13] flow_dissector: Add case in ipproto switch for NEXTHDR_NONE Tom Herbert

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=20240824191819.GU2164@kernel.org \
    --to=horms@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=felipe@sipanda.io \
    --cc=kuba@kernel.org \
    --cc=laforge@gnumonks.org \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=tom@herbertland.com \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=xeb@mail.ru \
    /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.