In the handle_read_event_rsp() function, after switching from RCU to SRCU
for accessing intf->users, the call to rcu_read_unlock() in the error
handling path was overlooked and not updated. According to SRCU usage
rules, srcu_read_unlock() should be used with the index returned by
srcu_read_lock(). Using rcu_read_unlock() instead is incorrect and can
lead to unpredictable behavior, such as data races or synchronization
issues.
This possible bug was identified using a static analysis tool developed
by myself, specifically designed to detect RCU-related issues.
To address this, srcu_read_unlock(&intf->users_srcu, index) is now called
in the error path, ensuring that the SRCU lock is correctly released
using the proper function and index. This prevents potential
synchronization issues and adheres to correct SRCU usage.
Fixes: e86ee2d44b44 ("ipmi: Rework locking and shutdown for hot remove")
Signed-off-by: Jiawei Ye <jiawei.ye@foxmail.com>
---
drivers/char/ipmi/ipmi_msghandler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c
index e12b531f5c2f..3ef46df78cdf 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -4426,7 +4426,7 @@ static int handle_read_event_rsp(struct ipmi_smi *intf,
recv_msg = ipmi_alloc_recv_msg();
if (!recv_msg) {
- rcu_read_unlock();
+ srcu_read_unlock(&intf->users_srcu, index);
list_for_each_entry_safe(recv_msg, recv_msg2, &msgs,
link) {
list_del(&recv_msg->link);
--
2.34.1