On Wed, Nov 12, 2025 at 11:02 AM Dan Jurgens <[email protected]> wrote: > > On 11/11/25 7:00 PM, Jason Wang wrote: > > On Tue, Nov 11, 2025 at 6:42 PM Paolo Abeni <[email protected]> wrote: > >> > >> On 11/7/25 5:15 AM, Daniel Jurgens wrote: > >>> @@ -7121,6 +7301,15 @@ static int virtnet_probe(struct virtio_device > >>> *vdev) > >>> } > >>> vi->guest_offloads_capable = vi->guest_offloads; > >>> > >>> + /* Initialize flow filters. Not supported is an acceptable and > >>> common > >>> + * return code > >>> + */ > >>> + err = virtnet_ff_init(&vi->ff, vi->vdev); > >>> + if (err && err != -EOPNOTSUPP) { > >>> + rtnl_unlock(); > >>> + goto free_unregister_netdev; > >> > >> I'm sorry for not noticing the following earlier, but it looks like that > >> the code could error out on ENOMEM even if the feature is not really > >> supported, when `cap_id_list` allocation fails, which in turn looks a > >> bit bad, as the allocated chunk is not that small (32K if I read > >> correctly). > >> > >> @Jason, @Micheal: WDYT? > > > > I agree. I think virtnet_ff_init() should be only called when the > > feature is negotiated. > > > > Thanks > > > > Are you suggesting we wait to call init until get/set_rxnfc is called? I > don't like that idea. Probe is the right time to do feature discovery.
Nope I meant it might be better: 1) embed virtio_admin_cmd_query_cap_id_result in virtnet_info to avoid dynamic allocation Or 2) at least check if there's an adminq before trying to call virtnet_ff_init()? Thanks > > > >> > >> /P > >> > > >
