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

[Paolo Abeni]

On 6/11/26 12:01 PM, Nitka, Grzegorz wrote:
>> -----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'?

The current guidance for the Fixes tag is to avoid it in net-next
patches, unless fixed patch is only present on net-next. My reading of
Jakub suggestion would be to drop the fixes tag as 'are not actually bugs.':

https://lore.kernel.org/netdev/20260604155422.167314ff@xxxxxxxxxx/

Note that I could misread his wording.

Fixes tag could be stripped when applying the patches as needed, and I
think that could be preferable to a repost just for such thing, given
the current PW load...

> 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.
... unless sashiko points to something really relevant. Please report on
the ML.

Thanks,

Paolo