Skip to contentSkip to conversation

rcu/kvfree: Add kvfree_rcu_barrier() API

PATCH In review Suren Baghdasaryan 2 participants 5 messages Nov 6, 2024 – Nov 7, 2024 Stable branch

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/2 rcu/kvfree: Add kvfree_rcu_barrier() API

From: Uladzislau Rezki <[email protected]>

commit 3c5d61ae919cc377c71118ccc76fa6e8518023f8 upstream.

Add a kvfree_rcu_barrier() function. It waits until all in-flight pointers are freed over RCU machinery. It does not wait any GP completion and it is within its right to return immediately if there are no outstanding pointers.

This function is useful when there is a need to guarantee that a memory is fully freed before destroying memory caches. For example, during unloading a kernel module.

---
Changes since v1 [1]:
- Added SOB, per Greg KH

[1] https://lore.kernel.org/all/[email protected]/

 include/linux/rcutiny.h |   5 ++
 include/linux/rcutree.h |   1 +
 kernel/rcu/tree.c       | 109 +++++++++++++++++++++++++++++++++++++---
 3 files changed, 107 insertions(+), 8 deletions(-)
include/linux/rcutiny.h +5 -0
index d9ac7b136aea..522123050ff8 100644
@@ -111,6 +111,11 @@ static inline void __kvfree_call_rcu(struct rcu_head *head, void *ptr)
 	kvfree(ptr);
 }
 
+static inline void kvfree_rcu_barrier(void)
+{
+	rcu_barrier();
+}
+
 #ifdef CONFIG_KASAN_GENERIC
 void kvfree_call_rcu(struct rcu_head *head, void *ptr);
 #else
include/linux/rcutree.h +1 -0
index 254244202ea9..58e7db80f3a8 100644
@@ -35,6 +35,7 @@ static inline void rcu_virt_note_context_switch(void)
 
 void synchronize_rcu_expedited(void);
 void kvfree_call_rcu(struct rcu_head *head, void *ptr);
+void kvfree_rcu_barrier(void);
 
 void rcu_barrier(void);
 void rcu_momentary_dyntick_idle(void);
kernel/rcu/tree.c +101 -8

136 lines not on this page · raw message

base-commit: 163b38476c50d64b89c1dfdf4fd57a368b6ebbec

Signature · 1 line
2.47.0.199.ga7371fff76-goog
#1 lore raw

PATCH v2 2/2 lib: alloc_tag_module_unload must wait for pending kfree_rcu calls

From: Florian Westphal <[email protected]>

commit dc783ba4b9df3fb3e76e968b2cbeb9960069263c upstream.

Ben Greear reports following splat:

 ------------[ cut here ]------------
 net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload
 WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0
 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat
...
 Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020
 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0
  codetag_unload_module+0x19b/0x2a0
  ? codetag_load_module+0x80/0x80

nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks.

Wait for outstanding kfree_rcu operations to complete before checking resolves this warning.

Reproducer:
unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat
rmmod nf_nat # will WARN.

---
Changes since v1 [1]:
- Added SOB, per Greg KH

[1] https://lore.kernel.org/all/[email protected]/

 lib/codetag.c | 3 +++
 1 file changed, 3 insertions(+)
lib/codetag.c +3 -0
index afa8a2d4f317..d1fbbb7c2ec3 100644
@@ -228,6 +228,9 @@ bool codetag_unload_module(struct module *mod)
 	if (!mod)
 		return true;
 
+	/* await any module's kfree_rcu() operations to complete */
+	kvfree_rcu_barrier();
+
 	mutex_lock(&codetag_lock);
 	list_for_each_entry(cttype, &codetag_types, link) {
 		struct codetag_module *found = NULL;
Signature · 1 line
2.47.0.199.ga7371fff76-goog
maintainer
#2 lore raw
In reply to Suren Baghdasaryan
Quoted 3 lines · Suren Baghdasaryan

From: Uladzislau Rezki <[email protected]>

commit 3c5d61ae919cc377c71118ccc76fa6e8518023f8 upstream.

No, that's not the right git id :(

This should be 2b55d6a42d14c8675e38d6d9adca3014fdf01951, right? Let me go change this...

thanks,

greg k-h

maintainer
#3 lore raw
Quoted 6 lines · Greg KH
Quoted 3 lines · Suren Baghdasaryan

From: Uladzislau Rezki <[email protected]>

commit 3c5d61ae919cc377c71118ccc76fa6e8518023f8 upstream.

No, that's not the right git id :(

But it is the git id of the fixup patch that I also need to take, so now grabbed, thanks for making me look :)

greg k-h

#4 lore raw
Quoted 11 lines · Greg KH
Quoted 6 lines · Greg KH
Quoted 3 lines · Suren Baghdasaryan

From: Uladzislau Rezki <[email protected]>

commit 3c5d61ae919cc377c71118ccc76fa6e8518023f8 upstream.

No, that's not the right git id :(

But it is the git id of the fixup patch that I also need to take, so now grabbed, thanks for making me look :)

Sorry for the confusion. Sounds like you sorted it out :)

Quoted 2 lines

greg k-h