From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7DB03112AB for ; Thu, 11 Jun 2026 14:41:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781188879; cv=none; b=L9+bW2TR5dTXCOzHRgSDx54ZA+LY3bLFlj7MZFWY/PY9v08x5LAapM9qPXmc4hhRNbgz0ibybBYQV5FnlWPyLO9HxXEHmto68bd4fly8f3ZYoYezNAZF0gEpNXP8iKW7TKnU+9lxQrE7vCXwxV91CfMXcKK1L+W9tGxu08HI3bQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781188879; c=relaxed/simple; bh=L+ZorF2xDuuSmKh6yuc+nw46rL9U0BR62/czr5/Eznw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=n8oIs4IRYUnInsoYv7FjomRIP2SfSm5j+kL/kuh2W4R8X48nKarZj9bnddLp++R1llDgkdNlqLTu+kiBh6wuBoGdfErbPpsCQiiwzz7OOnWRYxVtAj30uN4odr1SIIyENz6oGz5oU6rxozEL8dd81glcFeQFAj6n3lY05x3pqv8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=XEw8c8kT; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=muLvoXJ7; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XEw8c8kT"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="muLvoXJ7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781188873; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tyjEG+W9Hat2flkhk/jrtX0PYeov58aCgm5xfgox1ic=; b=XEw8c8kTU+2nQ8oTRuo/5i8F0bQ1ZQNgKcZtjhiGYYoWOIqQyotoxnO1OAjiVFmucGlVeK QmVF0dTwW5r+l85U6mj80aDEykdtMO0FFubeeigvsZaIfM+TpbZiNG/5xC2YhvJblMjFvr RRT4LemSgcBRVWdG9ZqfWeOecRS1c5I= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-483-7idDljVpOwmc-8aLGap0XQ-1; Thu, 11 Jun 2026 10:41:12 -0400 X-MC-Unique: 7idDljVpOwmc-8aLGap0XQ-1 X-Mimecast-MFC-AGG-ID: 7idDljVpOwmc-8aLGap0XQ_1781188871 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-45ef55779d1so5138156f8f.0 for ; Thu, 11 Jun 2026 07:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1781188871; x=1781793671; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tyjEG+W9Hat2flkhk/jrtX0PYeov58aCgm5xfgox1ic=; b=muLvoXJ7p5QvCglcteA21lhmiRAYEnnC+MTGOgzdb9royBmQX6Ci59XSsq4kPkCZZG Q9xBsncVhbxZDnw/qq8hyfQQzFLqgFADn1yaCcQOysSZ0LLAQCZSqSe037j6elP5YERe RBLRispJngaa56dQoLz/c3Egyv3MJXVtTCm2YP1yTifCHVIYKz36dDZTYMo4/C940/mA fg3odIFBdPl+8SelA/hbfWI/hlWLUZs2e9r8jIHTiGuCUJrgb909QBfXrD2uZ19XiYbc BZMDKxvFrpR4qT+bBqKLMMZJCN0meqZofR3Rxe2O6K8eQUGGA7LNTDDfjMxUH3H/Arfu 7jiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781188871; x=1781793671; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tyjEG+W9Hat2flkhk/jrtX0PYeov58aCgm5xfgox1ic=; b=oGXUdPDkU4sDNfiQH34Ihu3H5ecVRCqUGK4MEZLVtME3UcIaCXNzx7b3+VjmRD3u/4 Rh4CMZp/tzCezvHIaE6685Au93FLI8lbEIy2596gcsO06WyNOoZhikihRwXmZ1bYkgdz fHblwlFD6j00hDAUL3IoWIE+2CPbC2GmgXHFdt9CIZuvkWJQmRNmzg39lYG1EPIh5dJF aTrhVJ3MS3HVOxRfY+y3OyrLpV5+J2GOzmZU/RO7lyl/3QONxVzvAM/J9AVRWugKHomz pofdNqJaMU33hh5SJyBpIy/eXRD3qnAY41Dm5T0uhlKfeXoE6dCoBYVB/pmElGXRHWQx 5dKg== X-Gm-Message-State: AOJu0YxSVHkltNLrKrhPHwQVBBPgY0sBynbNN0lbN+fmhjZLgf+/XVaS RsYjbbSNVMWyEEyDy7QbTvHfahsdsrAc2SY7lWuY/RRS7+KKcwysuzz+Zpfa03EjfiICZDMBTKh +rqRTloWaHUBEULItXX2Who8NCcM2eIqMcm2X8aj2D262QmRLFHGs5Sy2BfbyUl8UAg== X-Gm-Gg: Acq92OHuOnv7bZREbqMxKabcEttgjMpDbCXjJdzyc3YbeNXZIC7DNA1Cch2F7lE42vn gs6KeTzlvQK7tg6JV5HBxkdZZDvTUlwm6625efY7NfZ6QAfmt6P0tTUsB9zgBWp1NcMGEXBDpfR h2mJus4dQgrrOSZ0x2lUhQtFcre/VigLU1Vx5y1eUICjKZupTiXz/p8y899ViKgFYpfBoDwUkaw THlvLpoMNDhzmIcdR6HDWaeguLo6NkQLx2UNm/XNcjFBKTErG/9tVn/nTSTAQpoS3qS8UPJYDdR /xoGbLz1NtGva5+Mwf1U6FmvYGorZsT1EADlWXo6xRPJxzYPoob6N5vftk7nuQA8aTsRl3oPTVR u19AZRdPlWBrnMuRwqjK5O+xzeo+IYQDAAjCMj8Bx9l30kbN6DsExDh0d5DLWRFE4mQ== X-Received: by 2002:adf:e844:0:b0:43d:1c21:ead5 with SMTP id ffacd0b85a97d-460675ab3f4mr3862514f8f.22.1781188870992; Thu, 11 Jun 2026 07:41:10 -0700 (PDT) X-Received: by 2002:adf:e844:0:b0:43d:1c21:ead5 with SMTP id ffacd0b85a97d-460675ab3f4mr3862474f8f.22.1781188870377; Thu, 11 Jun 2026 07:41:10 -0700 (PDT) Received: from [192.168.88.32] ([150.228.93.44]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2dcad5sm90601715f8f.5.2026.06.11.07.41.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2026 07:41:09 -0700 (PDT) Message-ID: <20be8f49-4d85-430b-a651-c4aecd172a57@redhat.com> Date: Thu, 11 Jun 2026 16:41:07 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v14 net-next 03/13] dpll: fix stale iteration in dpll_pin_on_pin_unregister() To: "Nitka, Grzegorz" , "netdev@vger.kernel.org" Cc: "linux-kernel@vger.kernel.org" , "intel-wired-lan@lists.osuosl.org" , "Oros, Petr" , "richardcochran@gmail.com" , "andrew+netdev@lunn.ch" , "Kitszel, Przemyslaw" , "Nguyen, Anthony L" , "Prathosh.Satish@microchip.com" , "Vecera, Ivan" , "jiri@resnulli.us" , "Kubalewski, Arkadiusz" , "vadim.fedorenko@linux.dev" , "donald.hunter@gmail.com" , "horms@kernel.org" , "kuba@kernel.org" , "davem@davemloft.net" , "edumazet@google.com" References: <20260607183045.1213735-1-grzegorz.nitka@intel.com> <20260607183045.1213735-4-grzegorz.nitka@intel.com> <5ad977af-9bbb-4376-b0a6-2b1867223145@redhat.com> From: Paolo Abeni Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/11/26 12:01 PM, Nitka, Grzegorz wrote: >> -----Original Message----- >> From: Paolo Abeni >> Sent: Thursday, June 11, 2026 10:50 AM >> To: Nitka, Grzegorz ; netdev@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org; Oros, Petr >> ; richardcochran@gmail.com; >> andrew+netdev@lunn.ch; Kitszel, Przemyslaw >> ; Nguyen, Anthony L >> ; Prathosh.Satish@microchip.com; Vecera, >> Ivan ; jiri@resnulli.us; Kubalewski, Arkadiusz >> ; 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 >> >> 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