On Wed, Feb 16, 2022 at 2:47 AM David Ahern <dsahern@xxxxxxxxxx> wrote:
>
> On 2/15/22 10:34 AM, Eric Dumazet wrote:
> >> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> >> index af94a6d22a9d..e3811afd1756 100644
> >> --- a/net/ipv4/tcp_input.c
> >> +++ b/net/ipv4/tcp_input.c
> >> @@ -4684,10 +4684,19 @@ static bool tcp_ooo_try_coalesce(struct sock *sk,
> >> return res;
> >> }
> >>
> >> -static void tcp_drop(struct sock *sk, struct sk_buff *skb)
> >> +static void tcp_drop_reason(struct sock *sk, struct sk_buff *skb,
> >> + enum skb_drop_reason reason)
> >> {
> >> sk_drops_add(sk, skb);
> >> - __kfree_skb(skb);
> >> + /* why __kfree_skb() used here before, other than kfree_skb()?
> >> + * confusing......
> >
> > Do not add comments like that if you do not know the difference...
> >
> > __kfree_skb() is used by TCP stack because it owns skb in receive
> > queues, and avoids touching skb->users
> > because it must be one already.
>
> and it bypasses kfree_skb tracepoint which seems by design.
Do you mean it shouldn't be traced here?
According to my understanding, __kfree_skb() was used in the
beginning as skb->users aren't touched by TCP. Later,
tcp_drop() was introduced to record drop count to the socket.
Considering the skb is indeed dropped and no other event is triggered,
is it ok to trigger the kfree_skb tracepoint?
Thanks!
Menglong Dong
