Re: [PATCH v18 net-next 1/2] octeontx2: use atomic bitops for PF/VF and rep flags

From: Ratheesh Kannoth

Date: Mon Oct 05 2026 - 00:18:06 EST


On 2026-10-02 at 14:01:14, netdev-bot+sashiko@xxxxxxxxxx (netdev-bot+sashiko@xxxxxxxxxx) wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider.
>
> Critical: 0 · High: 1 (3) · Medium: 1 (5) · Low: 0
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [High] otx2_sync_flags_from_rep() (otx2_common.h:625-634) updates the
> shared rep-PF flags word with a plain, non-atomic read-modify-write:…
> - [Medium] The patch quietly fixes a serious representor bug but gives it
> neither a Fixes: tag nor a description.

patch 1 is almost entirely mechanical (u64 masks → unsigned long + set_bit/clear_bit/test_bit)
It does not add new control flow. Reframed that way, every code issue Sashiko raised is a pre-existing defect
or race;

>
> Pre-existing issues:
> - [High] rvu_rep_destroy() (rep.c:637-643) calls free_netdev(rep->netdev)
> and then kfree(rep->flow_cfg).
> - [High] rep->stats_wrk is a delayed_work inside rep_dev, which is
> net_device private data.
> - [High] rvu_rep_mcam_flow_init() (rep.c:54-91) builds and sends NPC MCAM
> alloc mailbox messages (otx2_mbox_alloc_msg_npc_mcam_alloc_entry(),…
> - [Medium] otx2_tc_del_flow() (otx2_tc.c:1197-1198) clears
> OTX2_FLAG_TC_MARK_ENABLED on every delete of a mark flow, even when…
> - [Medium] rvu_rep_setup_tc_cb() (rep.c:115-121) ignores the return value
> of rvu_rep_mcam_flow_init() and then publishes rep->flow_cfg to…
> - [Medium] rvu_rep_mcam_flow_init() (rep.c:43-52) always overwrites
> rep->flow_cfg with a new kzalloc and never frees the previous one.
> - [Medium] rvu_rep_mcam_flow_init() allocates rep->flow_cfg with kzalloc
> and never calls refcount_set(&flow_cfg->mark_flows, 1).
> - [Medium] rvu_rep_state_evt_handler() (rep.c:297-309) uses the result of
> rvu_rep_get_repid() as an index into priv->reps[] without checking it,…