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

[Paolo Abeni <pabeni@redhat.com>]

On 6/11/26 12:01 PM, Nitka, Grzegorz wrote:
>> -----Original Message-----
>> From: Paolo Abeni <pabeni@redhat.com>
>> Sent: Thursday, June 11, 2026 10:50 AM
>> To: Nitka, Grzegorz <grzegorz.nitka@intel.com>; netdev@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org; Oros, Petr
>> <poros@redhat.com>; richardcochran@gmail.com;
>> andrew+netdev@lunn.ch; Kitszel, Przemyslaw
>> <przemyslaw.kitszel@intel.com>; Nguyen, Anthony L
>> <anthony.l.nguyen@intel.com>; Prathosh.Satish@microchip.com; Vecera,
>> Ivan <ivecera@redhat.com>; jiri@resnulli.us; Kubalewski, Arkadiusz
>> <arkadiusz.kubalewski@intel.com>; vadim.fedorenko@linux.dev;
>> donald.hunter@gmail.com; horms@kernel.org; kuba@kernel.org;
>> davem@davemloft.net; edumazet@google.com
>> 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@intel.com>
>>
>> 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@kernel.org/

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