Re: [PATCH net-next v6 1/8] net: add get_netmem/put_netmem support

[Jakub Kicinski]

On Tue, 4 Mar 2025 17:39:37 -0800 Mina Almasry wrote:
> > > Yes, great idea. I don't see why it wouldn't work.
> > >
> > > We don't expect mixing of net_iovs and pages in the same skb, but
> > > netdevsim could create one net_iov skb every N skbs.
> > >
> > > I guess I'm not totally sure something is discoverable to syzbot. Is a
> > > netdevsim hack toggleable via a debugfs sufficient for syzbot? I'll
> > > investigate and ask.  
> >
> > Yeah, my unreliable memory is that syzbot has a mixed record discovering
> > problems with debugfs. If you could ask Dmitry for advice that'd be
> > ideal.  
> 
> Yes, I took a look here and discussed with Willem. Long story short is
> that syzbot support is possible but with a handful of changes. We'll
> look into that.
> 
> Long story long, for syzbot support I don't think netdevsim itself
> will be useful. Its our understanding so far that syzbot doesn't do
> anything special with netdevsim.

Meaning it doesn't currently do anything special, or you can't make it
do anything special with netdevsim?

> We'll need to add queue API/page_pool/unreadable netmem support to
> one of the drivers qemu (syzbot) uses, and that should get syzbot
> fuzzing the control plane.
> 
> To get syzbot to fuzz the data plane, I think we need to set up a
> special syzbot instance which configures udmabuf/rss/flow

To be clear for Tx you don't need RSS and flow steering, Tx should
be trivial for any device driver which managers DMAs directly (not USB).

> steering/netlink binding and start injecting packets through the data
> path. Syzbot would not discover a working config on its own. I'm told
> it's rare to set up specialized syzbot instances but we could sell
> that this coverage is important enough.
> 
> Hacking netdevsim like you suggested would be useful as well, but
> outside of syzbot, AFAICT so far. We can run existing netdevsim data
> path tests with netdevsim in 'unreadable netmem mode' and see if it
> can reproduce issues. Although I'm not sure how to integrate that with
> continuous testing yet.