RE: [PATCH v14 net-next 03/13] dpll: fix stale iteration in dpll_pin_on_pin_unregister()

[Nitka, Grzegorz]

> -----Original Message-----
> From: Paolo Abeni <pabeni@xxxxxxxxxx>
> Sent: Thursday, June 11, 2026 10:50 AM
> To: Nitka, Grzegorz <grzegorz.nitka@xxxxxxxxx>; netdev@xxxxxxxxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx; intel-wired-lan@xxxxxxxxxxxxxxxx; Oros, Petr
> <poros@xxxxxxxxxx>; richardcochran@xxxxxxxxx;
> andrew+netdev@xxxxxxx; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; Nguyen, Anthony L
> <anthony.l.nguyen@xxxxxxxxx>; Prathosh.Satish@xxxxxxxxxxxxx; Vecera,
> Ivan <ivecera@xxxxxxxxxx>; jiri@xxxxxxxxxxx; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@xxxxxxxxx>; vadim.fedorenko@xxxxxxxxx;
> donald.hunter@xxxxxxxxx; horms@xxxxxxxxxx; kuba@xxxxxxxxxx;
> davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx
> Subject: Re: [PATCH v14 net-next 03/13] dpll: fix stale iteration in
> dpll_pin_on_pin_unregister()
> 
> On 6/7/26 8:30 PM, Grzegorz Nitka wrote:
> > Neither parent->dpll_refs nor pin->dpll_refs on its own is a correct
> > iteration target at unregister time:
> >
> >   - pin->dpll_refs includes DPLLs the child was registered against
> >     via a different parent or directly; blind unregister WARNs on
> >     the cookie miss in dpll_xa_ref_pin_del().
> >   - parent->dpll_refs reflects the parent's current attachments, not
> >     those at child-register time. Another driver may have (un)reg'd
> >     the parent against additional DPLLs in the meantime, so we miss
> >     registrations that exist and visit DPLLs that have none.
> >
> > Walk pin->dpll_refs and use dpll_pin_registration_find() to filter
> > to entries whose cookie is this parent. Symmetric with
> > dpll_pin_on_pin_register(), correct under any subsequent change to
> > parent->dpll_refs.
> >
> > Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions")
> > Signed-off-by: Grzegorz Nitka <grzegorz.nitka@xxxxxxxxx>
> 
> The current guidance is to avoid the Fixes tag for net-next patches,
> when such tag refers to code already into Linus's tree.
> 
> If it's a real user-visible issue, the patch should target net.
> Otherwise if the intended target is really net-next, no fixes tag please.
> 
> Unrelated important node: sashiko (gemini) still has some comments, some
> of them looks new and relevant to me i.e. the possible divide by zero
> bug in patch 11, see:
> 
> https://sashiko.dev/#/patchset/20260607183045.1213735-1-
> grzegorz.nitka%40intel.com
> 
> /P

Hi Paolo

Thanks for your feedback.
Regarding patches with 'Fixes' tag ...
Actually patches from 3 to 7 in this series are indeed fix patches for the existing code.
It was reported by Sashiko earlier for this series as pre-existing issues.
Kuba suggested, at least this is how I understood it, to include it in the series to see
a clean AI scan. 
So please advise on the next steps ...
Should I simply remove 'Fixes' tag from the commits and keep those patches in the series?
Or ...  to remove them from the series and re-send as regular fix patches on 'net'?

Regarding the latest Sahiko comments .. this specific one about divide-by-zero panic
is false-positive. It was fixed with the latest revision.
I'll respond in a separate message with my view on the other high ones.

Regards

Grzegorz