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 runyu.xiao@seu.edu.cn
Reviewed-by: Simon Horman horms@kernel.org
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.
...
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 runyu.xiao@seu.edu.cn
Reviewed-by: Simon Horman horms@kernel.org
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.
On Tue, Jul 07, 2026 at 04:51:12PM +0200, Pablo Neira Ayuso wrote:
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 runyu.xiao@seu.edu.cn
Reviewed-by: Simon Horman horms@kernel.org
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.
Hi Pablo,
Of course you are correct. Sorry for not realising this earlier.
On 7/8/26 12:35 PM, Simon Horman wrote:
On Tue, Jul 07, 2026 at 04:51:12PM +0200, Pablo Neira Ayuso wrote:
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 runyu.xiao@seu.edu.cn
Reviewed-by: Simon Horman horms@kernel.org
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.
Hi Pablo,
Of course you are correct. Sorry for not realising this earlier.
Human slop here made me wrongly apply this patch. Could either of you please share a formal revert?
Thanks!
Paolo
On Wed, Jul 08, 2026 at 01:10:58PM +0200, Paolo Abeni wrote:
On 7/8/26 12:35 PM, Simon Horman wrote:
On Tue, Jul 07, 2026 at 04:51:12PM +0200, Pablo Neira Ayuso wrote:
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 runyu.xiao@seu.edu.cn
Reviewed-by: Simon Horman horms@kernel.org
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.
Hi Pablo,
Of course you are correct. Sorry for not realising this earlier.
Human slop here made me wrongly apply this patch. Could either of you please share a formal revert?
Sure, will do.
On Wed, Jul 08, 2026 at 07:32:52PM +0100, Simon Horman wrote:
On Wed, Jul 08, 2026 at 01:10:58PM +0200, Paolo Abeni wrote:
On 7/8/26 12:35 PM, Simon Horman wrote:
On Tue, Jul 07, 2026 at 04:51:12PM +0200, Pablo Neira Ayuso wrote:
...
I think this patch is not correct.
Hi Pablo,
Of course you are correct. Sorry for not realising this earlier.
Human slop here made me wrongly apply this patch. Could either of you please share a formal revert?
Sure, will do.
- [PATCH net-next] Revert "gtp: annotate PDP lookups under RTNL" https://lore.kernel.org/netdev/20260708-gtp-rtnl-v1-1-218091f171bc@kernel.or...
On 7/8/26 9:04 PM, Simon Horman wrote:
On Wed, Jul 08, 2026 at 07:32:52PM +0100, Simon Horman wrote:
On Wed, Jul 08, 2026 at 01:10:58PM +0200, Paolo Abeni wrote:
On 7/8/26 12:35 PM, Simon Horman wrote:
On Tue, Jul 07, 2026 at 04:51:12PM +0200, Pablo Neira Ayuso wrote:
...
I think this patch is not correct.
Hi Pablo,
Of course you are correct. Sorry for not realising this earlier.
Human slop here made me wrongly apply this patch. Could either of you please share a formal revert?
Sure, will do.
- [PATCH net-next] Revert "gtp: annotate PDP lookups under RTNL" https://lore.kernel.org/netdev/20260708-gtp-rtnl-v1-1-218091f171bc@kernel.or...
Thanks Simon!
/P
osmocom-net-gprs@lists.osmocom.org
-
Pablo Neira Ayuso -
Paolo Abeni -
Simon Horman