[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YfCbIWlhgAxCX1qp@salvia>
Date: Wed, 26 Jan 2022 01:51:45 +0100
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Jakub Kicinski <kuba@...nel.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 Tue, Jan 25, 2022 at 03:32:14PM -0800, Jakub Kicinski wrote:
> 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.
I also think it's easier if you take it through net.git.
Thanks for asking.
Powered by blists - more mailing lists