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

[Ratheesh Kannoth <rkannoth@marvell.com>]

On 2026-10-02 at 14:01:14, netdev-bot+sashiko@kernel.org (netdev-bot+sashiko@kernel.org) 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,…