[PATCH net-next] netfilter: conntrack: dccp: try not to drop skb in conntrack

[PATCH net-next] netfilter: conntrack: dccp: try not to drop skb in conntrack

[Jason Xing]

From: Jason Xing <kernelxing@tencent.com>

It would be better not to drop skb in conntrack unless we have good
alternative as Florian said[1]. So we can treat the result of testing
skb's header pointer as nf_conntrack_tcp_packet() does.

[1]
Link: https://lore.kernel.org/all/20240307141025.GL4420@breakpoint.cc/

Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
 net/netfilter/nf_conntrack_proto_dccp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_conntrack_proto_dccp.c b/net/netfilter/nf_conntrack_proto_dccp.c
index e2db1f4ec2df..ebc4f733bb2e 100644
--- a/net/netfilter/nf_conntrack_proto_dccp.c
+++ b/net/netfilter/nf_conntrack_proto_dccp.c
@@ -525,7 +525,7 @@ int nf_conntrack_dccp_packet(struct nf_conn *ct, struct sk_buff *skb,
 
 	dh = skb_header_pointer(skb, dataoff, sizeof(*dh), &_dh.dh);
 	if (!dh)
-		return NF_DROP;
+		return -NF_ACCEPT;
 
 	if (dccp_error(dh, skb, dataoff, state))
 		return -NF_ACCEPT;
@@ -533,7 +533,7 @@ int nf_conntrack_dccp_packet(struct nf_conn *ct, struct sk_buff *skb,
 	/* pull again, including possible 48 bit sequences and subtype header */
 	dh = dccp_header_pointer(skb, dataoff, dh, &_dh);
 	if (!dh)
-		return NF_DROP;
+		return -NF_ACCEPT;
 
 	type = dh->dccph_type;
 	if (!nf_ct_is_confirmed(ct) && !dccp_new(ct, skb, dh, state))
-- 
2.37.3

[PATCH net-next] netfilter: conntrack: using NF_DROP in test statement in nf_conntrack_in()

[Jason Xing]

From: Jason Xing <kernelxing@tencent.com>

At the beginning in 2009 one patch [1] introduced collecting drop
counter in nf_conntrack_in() by returning -NF_DROP. Later, another
patch [2] changed the return value of tcp_packet() which now is
renamed to nf_conntrack_tcp_packet() from -NF_DROP to NF_DROP.

Well, as NF_DROP is equal to 0, inverting NF_DROP makes no sense
as patch [2] did many years ago.

[1]
commit 7d1e04598e5e ("netfilter: nf_conntrack: account packets drop by tcp_packet()")
[2]
commit ec8d540969da ("netfilter: conntrack: fix dropping packet after l4proto->packet()")

Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
 net/netfilter/nf_conntrack_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index c63868666bd9..6102dc09cdd3 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -2024,7 +2024,7 @@ nf_conntrack_in(struct sk_buff *skb, const struct nf_hook_state *state)
 			goto repeat;
 
 		NF_CT_STAT_INC_ATOMIC(state->net, invalid);
-		if (ret == -NF_DROP)
+		if (ret == NF_DROP)
 			NF_CT_STAT_INC_ATOMIC(state->net, drop);
 
 		ret = -ret;
-- 
2.37.3

Re: [PATCH net-next] netfilter: conntrack: dccp: try not to drop skb in conntrack

[Jason Xing]

On Fri, Mar 8, 2024 at 5:29 PM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> From: Jason Xing <kernelxing@tencent.com>
>
> It would be better not to drop skb in conntrack unless we have good
> alternative as Florian said[1]. So we can treat the result of testing
> skb's header pointer as nf_conntrack_tcp_packet() does.
>
> [1]
> Link: https://lore.kernel.org/all/20240307141025.GL4420@breakpoint.cc/
>
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
>  net/netfilter/nf_conntrack_proto_dccp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_proto_dccp.c b/net/netfilter/nf_conntrack_proto_dccp.c
> index e2db1f4ec2df..ebc4f733bb2e 100644
> --- a/net/netfilter/nf_conntrack_proto_dccp.c
> +++ b/net/netfilter/nf_conntrack_proto_dccp.c
> @@ -525,7 +525,7 @@ int nf_conntrack_dccp_packet(struct nf_conn *ct, struct sk_buff *skb,
>
>         dh = skb_header_pointer(skb, dataoff, sizeof(*dh), &_dh.dh);
>         if (!dh)
> -               return NF_DROP;
> +               return -NF_ACCEPT;
>
>         if (dccp_error(dh, skb, dataoff, state))
>                 return -NF_ACCEPT;
> @@ -533,7 +533,7 @@ int nf_conntrack_dccp_packet(struct nf_conn *ct, struct sk_buff *skb,
>         /* pull again, including possible 48 bit sequences and subtype header */
>         dh = dccp_header_pointer(skb, dataoff, dh, &_dh);
>         if (!dh)
> -               return NF_DROP;
> +               return -NF_ACCEPT;
>
>         type = dh->dccph_type;
>         if (!nf_ct_is_confirmed(ct) && !dccp_new(ct, skb, dh, state))
> --
> 2.37.3
>

I saw the status in patchwork was changed, but I've not received the
comments. So I spent some time learning how it works in the netfilter
area.

I just noticed that there are two trees (nf and nf-next), so should I
target nf-next and resend this patch and another one[1]?

[1]: https://lore.kernel.org/netfilter-devel/20240308092915.9751-2-kerneljasonxing@gmail.com/T/#m0ced362b380cff7e031d020e906ec2aa00669ce6

Thanks,
Jason

Re: [PATCH net-next] netfilter: conntrack: dccp: try not to drop skb in conntrack

[Jakub Kicinski]

On Mon, 11 Mar 2024 14:37:25 +0800 Jason Xing wrote:
> I saw the status in patchwork was changed, but I've not received the
> comments. So I spent some time learning how it works in the netfilter
> area.
> 
> I just noticed that there are two trees (nf and nf-next), so should I
> target nf-next and resend this patch and another one[1]?

I don't think you need to repost, you CCed the right people, they
should be able to process the patches. But do keep in mind the
netfilter trees on next patches.

Re: [PATCH net-next] netfilter: conntrack: dccp: try not to drop skb in conntrack

[Jason Xing]

On Mon, Mar 11, 2024 at 11:56 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 11 Mar 2024 14:37:25 +0800 Jason Xing wrote:
> > I saw the status in patchwork was changed, but I've not received the
> > comments. So I spent some time learning how it works in the netfilter
> > area.
> >
> > I just noticed that there are two trees (nf and nf-next), so should I
> > target nf-next and resend this patch and another one[1]?
>
> I don't think you need to repost, you CCed the right people, they
> should be able to process the patches. But do keep in mind the
> netfilter trees on next patches.

Thanks for the clarification :)