> > - if (resp.hdr.response.msg_version >= GDMA_MESSAGE_V2)
> > + if (resp.hdr.response.msg_version >= GDMA_MESSAGE_V2) {
> > + if (resp.adapter_mtu < ETH_MIN_MTU + ETH_HLEN) {
> > + dev_err(dev, "Adapter MTU too small: %u\n",
> > + resp.adapter_mtu);
> > + return -EPROTO;
>
> AI review says:
>
> If this returns -EPROTO, does the caller mana_probe() jump to an error
> label and call mana_remove()?
> If so, mana_remove() unconditionally calls
> disable_work_sync(&ac->link_change_work) and
> cancel_delayed_work_sync(&ac->gf_stats_work).
> Since mana_query_device_cfg() is called before INIT_WORK() and
> INIT_DELAYED_WORK() in the probe sequence, wouldn't this result in
> calling sync cancellation functions on uninitialized, zeroed work
> structures?
> This can lead to a WARN_ON(!work->func) in __flush_work(), or debug
> object warnings if CONFIG_DEBUG_OBJECTS_WORK is enabled.
> While this initialization issue appears to already exist for other early
> error paths, this new error path can also trigger it.
Thankyou for the review.
Since the issue is pre-existing. I will send it in a separate patchset.
The patchset will include the the issue reported with:
[PATCH net-next] net: mana: hardening: Reject zero max_num_queues from
MANA_QUERY_VPORT_CONFIG
- Vennela
