linux-kernel - Re: [PATCH] net: tcp_drop adds `reason` and SNMP parameters for tracing v4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 4 Sep 2021 12:04:04 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Zhongya Yan <yan2228598786@...il.com>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        David Miller <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        dsahern@...nel.org, hengqi.chen@...il.com,
        Yonghong Song <yhs@...com>,
        Brendan Gregg <brendan.d.gregg@...il.com>, 2228598786@...com
Subject: Re: [PATCH] net: tcp_drop adds `reason` and SNMP parameters for
 tracing v4

On Fri, Sep 3, 2021 at 11:43 PM Zhongya Yan <yan2228598786@...il.com> wrote:
>
> I used the suggestion from `Brendan Gregg`. In addition to the
> `reason` parameter there is also the `field` parameter pointing
> to `SNMP` to distinguish the `tcp_drop` cause. I know what I
> submitted is not accurate, so I am submitting the current
> patch to get comments and criticism from everyone so that I
> can submit better code and solutions.And of course to make me
> more familiar and understand the `linux` kernel network code.

Any reason why only limit this to TCP? I am pretty sure we are
interested in packet drops across the entire stack.

You can take a look at net/core/drop_monitor.c, it actually has
a big advantage over your solution, which is sending entire
dropped packets to user-space for inspection.

If you can have a solution for all packet drops, not just TCP,
it would make your patch much more useful. Therefore, I'd
suggest you to consider extending the drop monitor.

Thanks.