netdev - Re: [PATCH v2 net-next 2/3] pfcp: Convert pfcp_net_exit() to ->exit

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: <aAnAxEXgyyhfgHWw@mev-dev.igk.intel.com>
Date: Thu, 24 Apr 2025 06:40:36 +0200
From: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>,
	Wojciech Drewek <wojciech.drewek@...el.com>,
	Kuniyuki Iwashima <kuniyu@...zon.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>,
	Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org,
	marcin.szycik@...el.com
Subject: Re: [PATCH v2 net-next 2/3] pfcp: Convert pfcp_net_exit() to
 ->exit_rtnl().

On Wed, Apr 23, 2025 at 06:33:50AM -0700, Jakub Kicinski wrote:
> On Wed, 23 Apr 2025 10:37:05 +0200 Michal Swiatkowski wrote:
> > On Tue, Apr 22, 2025 at 07:47:57PM -0700, Jakub Kicinski wrote:
> > > On Thu, 17 Apr 2025 17:32:33 -0700 Kuniyuki Iwashima wrote:  
> > > >  drivers/net/pfcp.c | 23 +++++++----------------  
> > > 
> > > Wojciech, Michał, does anyone use this driver?
> > > It seems that it hooks dev_get_tstats64 as ndo_get_stats64 
> > > but it never allocates tstats, so any ifconfig / ip link
> > > run after the device is create immediately crashes the kernel.
> > > I don't see any tstats in this driver history or UDP tunnel
> > > code so I'm moderately confused as how this worked / when
> > > it broke.
> > > 
> > > If I'm not missing anything and indeed this driver was always
> > > broken we should just delete it ?  
> > 
> > Uh, I remember that we used it to add tc filter. Maybe we can fix it?
> 
> If it really was broken for over a year and nobody noticed -
> my preference would be to delete it. I don't think you need
> an actual tunnel dev to add TC filters?

Our approach was to follow scheme from exsisting ones.
For example, vxlan filter:
tc filter add dev vxlan ingress protocol ip ...
PFCP filter:
tc filter add dev pfcp ingress protocol ip ...

so in this case we need sth to point and pass the information that this
tunnel is PFCP. If you have an idea how to do it without actual tunnel
we are willing to implement it. AFAIR simple matching on specific port
number isn't good solution as tunnel specific fields can't be passed in
such scenario.

Thanks