From: Jianguo Wu <wujianguo@chinatelecom.cn>

Using consume_skb() instead of kfree_skb_reason() after do normally
time wait process to be drop monitor friendly.

Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
---
 net/ipv4/tcp_ipv4.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f9cec62..957d86c 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2154,7 +2154,9 @@ int tcp_v4_rcv(struct sk_buff *skb)
 		goto discard_it;
 	case TCP_TW_SUCCESS:;
 	}
-	goto discard_it;
+
+	consume_skb(skb);
+	return 0;
 }

 static struct timewait_sock_ops tcp_timewait_sock_ops = {
-- 
1.8.3.1

On Wed, Mar 23, 2022 at 6:05 AM Jianguo Wu <wujianguo106@163.com> wrote:
>
> From: Jianguo Wu <wujianguo@chinatelecom.cn>
>
> Using consume_skb() instead of kfree_skb_reason() after do normally
> time wait process to be drop monitor friendly.
>
> Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
> ---
>

1) net-next is closed.

2) This seems pretty much random to me, we definitely reach this point
with packets that are dropped.

These are classified as drops.

You know, TCP can handle reordered packets, spurious retransmits, and
stuff like that, we do not want to hide this,
otherwise we would have used consume_skb() for all packets.

After all, TCP handles all incoming packets 'normally'.

If you really care, I suggest you change (when net-next reopens in two
weeks) the @reason to more precisely describe what is happening.