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.