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.
