From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.netfilter.org (mail.netfilter.org [217.70.190.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 295EF36F912; Tue, 7 Jul 2026 14:51:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.190.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783435880; cv=none; b=jgGfyUj1HRpAiXZMdcwDWGwhglFuH+r2gLXcE8HiBRhxPdGPuNaHnI4g6C7UvTgCBg9o+gqFCczK7tP83JQH/hIMxJK8Wz9Jm4wpqzCBpQ4V6kGv+xDlm/irfGlGe3bErSLj05NCGddVBtUcxOsr77/jU+5P1AO06rfQpqTkIy4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783435880; c=relaxed/simple; bh=L9pxNODWKGKAuUCsthtXuF8mIBH7L4Qzn2ryWaBeMOU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=S1nq/Zw2T3iutwclBHnsEd0sv5f62gnsayjBAVojvkZiuRRyqPYYdO7B3kmyaY4XHNGmZ8PzsGiR58qoUCMGcVfns8qFjvJVa9ipJLNYt5Glp8D3OhWTj7J2AUBlkQLtHcmjQ6qgZA7NKPqc/z04kPM46lfamNSd3Y5S6cl4oic= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=netfilter.org; spf=pass smtp.mailfrom=netfilter.org; dkim=pass (2048-bit key) header.d=netfilter.org header.i=@netfilter.org header.b=aR4VJX9a; arc=none smtp.client-ip=217.70.190.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=netfilter.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=netfilter.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=netfilter.org header.i=@netfilter.org header.b="aR4VJX9a" Received: from netfilter.org (mail-agni [217.70.190.124]) by mail.netfilter.org (Postfix) with UTF8SMTPSA id 9F22560581; Tue, 7 Jul 2026 16:51:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netfilter.org; s=2025; t=1783435875; bh=gt9EUNIkxSF/HxvT4+/9rtfn5HBwdYBkGcy8bzzqMU8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aR4VJX9a0lT4k9RgfZhExBrDXRGUzS7AoA51CHfEL2KNL1oAInOVY65NfNkS4a194 rxvdatytP7zN8L80/1RejAhfLRbXPpxDIFHiYXhM2p9ElKBlKezwe57ldSDeS5ITS5 pplEuB28dm/CYaFJ+S0kyhbSpfgsH2ZYdYsE8kKllun3Q79DvRKeL/4uz4UXINnbvv cAZqvc59Utem2Chghcg+66CSJ2ITL3ZtMbSNOIkK2+iLh4uM6cjosMqV2g9cIXU8O7 pEnP53NxY082Zr3DnPGYV7GtiEcuHtimKPoG9sml53gan3rkih6RXfWwpu0o+mtArX lhHIrCAybxR0w== Date: Tue, 7 Jul 2026 16:51:12 +0200 From: Pablo Neira Ayuso To: Simon Horman Cc: Runyu Xiao , laforge@gnumonks.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, osmocom-net-gprs@lists.osmocom.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jianhao.xu@seu.edu.cn Subject: Re: [PATCH net-next] gtp: annotate PDP lookups under RTNL Message-ID: References: <20260701123925.3193089-1-runyu.xiao@seu.edu.cn> <20260707142820.GG1364329@horms.kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260707142820.GG1364329@horms.kernel.org> Hi Simon, On Tue, Jul 07, 2026 at 03:28:20PM +0100, Simon Horman wrote: > On Wed, Jul 01, 2026 at 08:39:25PM +0800, Runyu Xiao wrote: > > The GTP PDP lookup helpers are shared by RCU-protected data and report > > paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The > > helpers walk RCU hlists, but they do not currently pass the RTNL > > condition for the control-path lookups. > > > > Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing > > RCU-reader callers remain valid because the RCU-list macros also accept > > an active RCU read-side section; the added condition only documents the > > non-RCU protection already used by RTNL control paths. > > > > This was found by our static analysis tool and then manually reviewed > > against the current tree. The dynamic triage evidence is a > > target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited > > to documenting the existing protection contract. > > > > This is a lockdep annotation cleanup. It does not change PDP lifetime or > > hash updates. > > > > Signed-off-by: Runyu Xiao > > Reviewed-by: Simon Horman > > There is an AI-generated review of this patch available on sashko.dev. > While I don't believe that the issues raised there should impede progress > of this patch you may want to look into them as possible follow-up. This patch refers to the rtnl_lock, but it is the genetlink mutex that protects updates on the PDP context list. Then, from packet path, rcu lookups are performed. I think this patch is not correct.