[PATCH net] selftests/bpf: set gopt opt_class to 0 if get tunnel opt failed

When fixing the bpf test_tunnel.sh genve failure. I only fixed
the IPv4 part but forgot the IPv6 issue. Similar with the IPv4
fixes 557c223b643a ("selftests/bpf: No need to drop the packet when
there is no geneve opt"), when there is no tunnel option and
bpf_skb_get_tunnel_opt() returns error, there is no need to drop the
packets and break all geneve rx traffic. Just set opt_class to 0 and
keep returning TC_ACT_OK at the end.

Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
Signed-off-by: Hangbin Liu <redacted>
---
 tools/testing/selftests/bpf/progs/test_tunnel_kern.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
index 9afe947cfae9..ba6eadfec565 100644
--- a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
+++ b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c

@@ -508,10 +508,8 @@ int _ip6geneve_get_tunnel(struct __sk_buff *skb)
 	}
 
 	ret = bpf_skb_get_tunnel_opt(skb, &gopt, sizeof(gopt));
-	if (ret < 0) {
-		ERROR(ret);
-		return TC_ACT_SHOT;
-	}
+	if (ret < 0)
+		gopt.opt_class = 0;
 
 	bpf_trace_printk(fmt, sizeof(fmt),
 			key.tunnel_id, key.remote_ipv4, gopt.opt_class);

-- 
2.26.2

On Mon, Mar 8, 2021 at 7:22 PM Hangbin Liu [off-list ref] wrote:

When fixing the bpf test_tunnel.sh genve failure. I only fixed
the IPv4 part but forgot the IPv6 issue. Similar with the IPv4
fixes 557c223b643a ("selftests/bpf: No need to drop the packet when
there is no geneve opt"), when there is no tunnel option and
bpf_skb_get_tunnel_opt() returns error, there is no need to drop the
packets and break all geneve rx traffic. Just set opt_class to 0 and
keep returning TC_ACT_OK at the end.

Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
Signed-off-by: Hangbin Liu <redacted>
---

LGTM, thanks.
Acked-by: William Tu <redacted>

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Tue,  9 Mar 2021 11:22:14 +0800 you wrote:

When fixing the bpf test_tunnel.sh genve failure. I only fixed
the IPv4 part but forgot the IPv6 issue. Similar with the IPv4
fixes 557c223b643a ("selftests/bpf: No need to drop the packet when
there is no geneve opt"), when there is no tunnel option and
bpf_skb_get_tunnel_opt() returns error, there is no need to drop the
packets and break all geneve rx traffic. Just set opt_class to 0 and
keep returning TC_ACT_OK at the end.

[...]

Here is the summary with links:
  - [net] selftests/bpf: set gopt opt_class to 0 if get tunnel opt failed
    https://git.kernel.org/netdev/net-next/c/557c223b643a

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

On Wed, Mar 10, 2021 at 01:37:48AM +0000, patchwork-bot+netdevbpf@kernel.org wrote:

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Tue,  9 Mar 2021 11:22:14 +0800 you wrote:

quoted

When fixing the bpf test_tunnel.sh genve failure. I only fixed
the IPv4 part but forgot the IPv6 issue. Similar with the IPv4
fixes 557c223b643a ("selftests/bpf: No need to drop the packet when
there is no geneve opt"), when there is no tunnel option and
bpf_skb_get_tunnel_opt() returns error, there is no need to drop the
packets and break all geneve rx traffic. Just set opt_class to 0 and
keep returning TC_ACT_OK at the end.

[...]

Here is the summary with links:
  - [net] selftests/bpf: set gopt opt_class to 0 if get tunnel opt failed
    https://git.kernel.org/netdev/net-next/c/557c223b643a

Hi bot,

I think you are mixing this patch with commit

557c223b643a ("selftests/bpf: No need to drop the packet when there is no geneve opt")

Thanks
Hangbin

Hi David,

May I ask what's the status of this patch? From patchwork[1] the state is
accepted. But I can't find the fix on net or net-next.

[1] https://patchwork.kernel.org/project/netdevbpf/patch/20210309032214.2112438-1-liuhangbin@gmail.com/

Thanks
Hangbin
On Tue, Mar 09, 2021 at 11:22:14AM +0800, Hangbin Liu wrote:

On 3/12/21 2:56 AM, Hangbin Liu wrote:

Hi David,

May I ask what's the status of this patch? From patchwork[1] the state is
accepted. But I can't find the fix on net or net-next.

I think there may have been two confusions, i) that $subject says that this goes
via net tree instead of bpf tree, which might have caused auto-delegation to move
this into 'netdev' patchwork reviewer bucket, and ii) the kernel patchwork bot then
had a mismatch as you noticed when it checked net-next after tree merge and replied
to the wrong patch of yours which then placed this one into 'accepted' state. I just
delegated it to bpf and placed it back under review..

[1] https://patchwork.kernel.org/project/netdevbpf/patch/20210309032214.2112438-1-liuhangbin@gmail.com/

Thanks
Hangbin

On Tue, Mar 09, 2021 at 11:22:14AM +0800, Hangbin Liu wrote:

quoted

When fixing the bpf test_tunnel.sh genve failure. I only fixed
the IPv4 part but forgot the IPv6 issue. Similar with the IPv4
fixes 557c223b643a ("selftests/bpf: No need to drop the packet when
there is no geneve opt"), when there is no tunnel option and
bpf_skb_get_tunnel_opt() returns error, there is no need to drop the
packets and break all geneve rx traffic. Just set opt_class to 0 and
keep returning TC_ACT_OK at the end.

Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
Signed-off-by: Hangbin Liu <redacted>
---
  tools/testing/selftests/bpf/progs/test_tunnel_kern.c | 6 ++----
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
index 9afe947cfae9..ba6eadfec565 100644
--- a/tools/testing/selftests/bpf/progs/test_tunnel_kern.c
+++ b/tools/testing/selftests/bpf/progs/test_tunnel_kern.c

@@ -508,10 +508,8 @@ int _ip6geneve_get_tunnel(struct __sk_buff *skb)
  	}
  
  	ret = bpf_skb_get_tunnel_opt(skb, &gopt, sizeof(gopt));
-	if (ret < 0) {
-		ERROR(ret);
-		return TC_ACT_SHOT;
-	}
+	if (ret < 0)
+		gopt.opt_class = 0;
  
  	bpf_trace_printk(fmt, sizeof(fmt),
  			key.tunnel_id, key.remote_ipv4, gopt.opt_class);

-- 
2.26.2

On Fri, Mar 12, 2021 at 04:15:27PM +0100, Daniel Borkmann wrote:

On 3/12/21 2:56 AM, Hangbin Liu wrote:

quoted

Hi David,

May I ask what's the status of this patch? From patchwork[1] the state is
accepted. But I can't find the fix on net or net-next.

I think there may have been two confusions, i) that $subject says that this goes
via net tree instead of bpf tree, which might have caused auto-delegation to move
this into 'netdev' patchwork reviewer bucket, and ii) the kernel patchwork bot then
had a mismatch as you noticed when it checked net-next after tree merge and replied
to the wrong patch of yours which then placed this one into 'accepted' state. I just
delegated it to bpf and placed it back under review..

quoted

[1] https://patchwork.kernel.org/project/netdevbpf/patch/20210309032214.2112438-1-liuhangbin@gmail.com/

Thanks Daniel, I thought the issue also exists on net tree and is a fixup. So
I set the target to 'net'.

Hangbin

On 3/15/21 7:57 AM, Hangbin Liu wrote:

On Fri, Mar 12, 2021 at 04:15:27PM +0100, Daniel Borkmann wrote:

quoted

On 3/12/21 2:56 AM, Hangbin Liu wrote:

quoted

Hi David,

May I ask what's the status of this patch? From patchwork[1] the state is
accepted. But I can't find the fix on net or net-next.

I think there may have been two confusions, i) that $subject says that this goes
via net tree instead of bpf tree, which might have caused auto-delegation to move
this into 'netdev' patchwork reviewer bucket, and ii) the kernel patchwork bot then
had a mismatch as you noticed when it checked net-next after tree merge and replied
to the wrong patch of yours which then placed this one into 'accepted' state. I just
delegated it to bpf and placed it back under review..

quoted

[1] https://patchwork.kernel.org/project/netdevbpf/patch/20210309032214.2112438-1-liuhangbin@gmail.com/

Thanks Daniel, I thought the issue also exists on net tree and is a fixup. So
I set the target to 'net'.

Sure; in the end this gets routed via bpf to net tree given it's bpf selftests, so
$subj should target bpf. Anyway, applied now, thanks!