[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89i+C-qk-WhEanMS_tRiYJHHixH33MAO3u-wQVdWGJOjskw@mail.gmail.com>
Date: Mon, 26 May 2025 01:35:55 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: jiang.kun2@....com.cn
Cc: davem@...emloft.net, kuba@...nel.org, dsahern@...nel.org,
pabeni@...hat.com, horms@...nel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, xu.xin16@....com.cn, yang.yang29@....com.cn,
wang.yaxin@....com.cn, fan.yu9@....com.cn, he.peilin@....com.cn,
tu.qiang35@....com.cn, qiu.yutan@....com.cn, zhang.yunkai@....com.cn,
ye.xingchen@....com.cn
Subject: Re: [PATCH net-next] net: arp: use kfree_skb_reason() in arp_rcv()
On Mon, May 26, 2025 at 1:27 AM <jiang.kun2@....com.cn> wrote:
>
> From: Qiu Yutan <qiu.yutan@....com.cn>
>
> Replace kfree_skb() with kfree_skb_reason() in arp_rcv(). Following
> new skb drop reasons are introduced for arp:
>
> /* ARP header hardware address length mismatch */
> SKB_DROP_REASON_ARP_HLEN_MISMATCH
> /* ARP header protocol addresslength is invalid */
> SKB_DROP_REASON_ARP_PLEN_INVALID
Are these errors common enough to get dedicated drop reasons ? Most
stacks have implemented ARP more than 20 years ago.
I think that for rare events like this, the standard call graph should
be plenty enough. (perf record -ag -e skb:kfree_skb)
Otherwise we will get 1000 drop reasons, and the profusion of names
makes them useless.
Powered by blists - more mailing lists