Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <0f6d4f89-c08d-b985-075e-a763fec87fc4@163.com>
In-Reply-To: <0f6d4f89-c08d-b985-075e-a763fec87fc4@163.com>
From:   Eric Dumazet <edumazet@google.com>
Date:   Wed, 23 Mar 2022 06:25:43 -0700
Message-ID: <CANn89iKs0W=_HixT7_2R0xBrwEMEvin1-JHijjDNeMOqLKLmpg@mail.gmail.com>
Subject: Re: [PATCH net-next] tcp: consume packet after do time wait process
To:     Jianguo Wu <wujianguo106@163.com>
Cc:     Menglong Dong <menglong8.dong@gmail.com>,
        David Ahern <dsahern@kernel.org>,
        Jakub Kicinski <kuba@kernel.org>,
        netdev <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.