[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220125153214.180d2c09@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date: Tue, 25 Jan 2022 15:32:14 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: pablo@...filter.org
Cc: menglong8.dong@...il.com, rostedt@...dmis.org, mingo@...hat.com,
davem@...emloft.net, yoshfuji@...ux-ipv6.org, dsahern@...nel.org,
kadlec@...filter.org, fw@...len.de, imagedong@...cent.com,
edumazet@...gle.com, alobakin@...me, paulb@...dia.com,
pabeni@...hat.com, talalahmad@...gle.com, haokexin@...il.com,
keescook@...omium.org, memxor@...il.com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
cong.wang@...edance.com
Subject: Re: [PATCH net-next 1/6] net: netfilter: use kfree_drop_reason()
for NF_DROP
On Mon, 24 Jan 2022 21:15:33 +0800 menglong8.dong@...il.com wrote:
> From: Menglong Dong <imagedong@...cent.com>
>
> Replace kfree_skb() with kfree_skb_reason() in nf_hook_slow() when
> skb is dropped by reason of NF_DROP.
Netfilter folks, does this look good enough to you?
Do you prefer to take the netfilter changes via your tree? I'm asking
because enum skb_drop_reason is probably going to be pretty hot so if
the patch is simple enough maybe no point dealing with merge conflicts.
Powered by blists - more mailing lists