Skip to contentSkip to conversation

net/ncsi: use kfree_rcu_mightsleep for RCU-protected list entries

PATCH New Tristan Madani 2 participants 2 messages Nov 11

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 net/ncsi: use kfree_rcu_mightsleep for RCU-protected list entries

From: Tristan Madani <[email protected]>

ncsi_remove_channel(), ncsi_remove_package(), and ncsi_unregister_dev() each call list_del_rcu() to remove an entry from an RCU-protected list, then immediately call kfree(). Concurrent RCU readers traversing the list may still hold references to the freed object.

A similar pattern was already fixed in the VLAN list, but these three sites were missed.

Replace kfree() with kfree_rcu_mightsleep() to defer the free until after an RCU grace period.

Fixes 2d283bdd5b20 ("net/ncsi: Package and channel management")
---
 net/ncsi/ncsi-manage.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
net/ncsi/ncsi-manage.c +3 -3
index 54d0df0a9efe6..64274a5058346 100644
@@ -263,7 +263,7 @@ static void ncsi_remove_channel(struct ncsi_channel *nc)
 	np->channel_num--;
 	spin_unlock_irqrestore(&np->lock, flags);
 
-	kfree(nc);
+	kfree_rcu_mightsleep(nc);
 }
 
 struct ncsi_package *ncsi_find_package(struct ncsi_dev_priv *ndp,
@@ -326,7 +326,7 @@ void ncsi_remove_package(struct ncsi_package *np)
 	ndp->package_num--;
 	spin_unlock_irqrestore(&ndp->lock, flags);
 
-	kfree(np);
+	kfree_rcu_mightsleep(np);
 }
 
 void ncsi_find_package_and_channel(struct ncsi_dev_priv *ndp,
@@ -1969,6 +1969,6 @@ void ncsi_unregister_dev(struct ncsi_dev *nd)
 
 	disable_work_sync(&ndp->work);
 
-	kfree(ndp);
+	kfree_rcu_mightsleep(ndp);
 }
 EXPORT_SYMBOL_GPL(ncsi_unregister_dev);
Signature · 1 line
2.47.3
#1 lore raw
This is an automated message. This series looks like a fix, but its commit messages seem to be missing some information:

Hi!

This is an automated message. This series looks like a fix, but its commit messages seem to be missing some information:

- How the issue was discovered, e.g. hit in production, hit during development, syzbot report, manual code inspection, LLM or static analysis tool scan.

- Whether the issue was actually triggered, or is only theoretical (e.g. found by LLM and not proven at runtime). If it was triggered please include the symptoms, like the stack trace or kernel messages.

Please do not repost the series just to address the above. Instead, reply to this email with the missing information, so that reviewers can take it into account. If the series needs another revision for other reasons, please include the information in the commit messages then.

The evaluation is done by an LLM so it may be wrong, if you think that is the case please reply and explain.