netdev - Re: [PATCH net-next v7 08/12] net: vxlan: use kfree_skb_reason() in vxlan

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]

Message-ID: <Zw09Gs26YDUniCI4@shredder.mtl.com>
Date: Mon, 14 Oct 2024 18:47:38 +0300
From: Ido Schimmel <idosch@...dia.com>
To: Menglong Dong <menglong8.dong@...il.com>
Cc: kuba@...nel.org, aleksander.lobakin@...el.com, horms@...nel.org,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	dsahern@...nel.org, dongml2@...natelecom.cn, amcohen@...dia.com,
	gnault@...hat.com, bpoirier@...dia.com, b.galvani@...il.com,
	razor@...ckwall.org, petrm@...dia.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v7 08/12] net: vxlan: use kfree_skb_reason() in
 vxlan_xmit()

On Mon, Oct 14, 2024 at 08:35:57PM +0800, Menglong Dong wrote:
> On Sun, Oct 13, 2024 at 8:43 PM Ido Schimmel <idosch@...dia.com> wrote:
> >
> > On Wed, Oct 09, 2024 at 10:28:26AM +0800, Menglong Dong wrote:
> > > Replace kfree_skb() with kfree_skb_reason() in vxlan_xmit(). Following
> > > new skb drop reasons are introduced for vxlan:
> > >
> > > /* no remote found for xmit */
> > > SKB_DROP_REASON_VXLAN_NO_REMOTE
> > > /* packet without necessary metadata reached a device which is
> > >  * in "external" mode
> > >  */
> > > SKB_DROP_REASON_TUNNEL_TXINFO
> > >
> > > Signed-off-by: Menglong Dong <dongml2@...natelecom.cn>
> > > Reviewed-by: Simon Horman <horms@...nel.org>
> >
> > Reviewed-by: Ido Schimmel <idosch@...dia.com>
> >
> > The first reason might be useful for the bridge driver as well when
> > there are no ports to forward the packet to (because of egress filtering
> > for example), but we can make it more generic if / when the bridge
> > driver is annotated.
> 
> You are right. As we already need a new version, so we can
> do something for this patch too. As you said, maybe we can rename the
> reason VXLAN_NO_REMOTE to NO_REMOTE for more generic
> usage?

"NO_REMOTE" is not really applicable to the bridge driver as there are
no remotes, but bridge ports. I'm fine with keeping it as is for now and
changing it later if / when needed.