[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89iL43q7tCETt3gW9L_HVHdRrovu9mauekA3QrWrpVSm+Ow@mail.gmail.com>
Date: Wed, 28 May 2025 06:22:53 -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 4:47 AM <jiang.kun2@....com.cn> wrote:
>
> >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.
>
> Thank you for your feedback.
>
> Maliciously crafted ARP packets often trigger these two scenarios.
> Using perf cannot directly distinguish between the two cases;
> additionally, enabling perf in embedded environments may lead to
> noticeable performance overhead.
ARP packets are local to the domain. They are not a concern, really.
If your local domain has 'malicious hosts', they could actually
trigger more issues by sending
complete packets, to make sure to fill various hash tables.
Powered by blists - more mailing lists