On 6/11/26 12:01 PM, Nitka, Grzegorz wrote: >> -----Original Message----- >> From: Paolo Abeni <[email protected]> >> Sent: Thursday, June 11, 2026 10:50 AM >> To: Nitka, Grzegorz <[email protected]>; [email protected] >> Cc: [email protected]; [email protected]; Oros, >> Petr >> <[email protected]>; [email protected]; >> [email protected]; Kitszel, Przemyslaw >> <[email protected]>; Nguyen, Anthony L >> <[email protected]>; [email protected]; Vecera, >> Ivan <[email protected]>; [email protected]; Kubalewski, Arkadiusz >> <[email protected]>; [email protected]; >> [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected] >> 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 <[email protected]> >> >> 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/[email protected]/ 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
