From: pengdonglin <pengdong...@xiaomi.com>
Since commit a8bb74acd8efe ("rcu: Consolidate RCU-sched update-side function
definitions")
there is no difference between rcu_read_lock(), rcu_read_lock_bh() and
rcu_read_lock_sched() in terms of RCU read section and the relevant grace
period. That means that spin_lock(), which implies rcu_read_lock_sched(),
also implies rcu_read_lock().
There is no need no explicitly start a RCU read section if one has already
been started implicitly by spin_lock().
Simplify the code and remove the inner rcu_read_lock() invocation.
Cc: "Rafael J. Wysocki" <raf...@kernel.org>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Hanjun Guo <guohan...@huawei.com>
Signed-off-by: pengdonglin <pengdong...@xiaomi.com>
Signed-off-by: pengdonglin <dolinux.p...@gmail.com>
---
drivers/acpi/apei/ghes.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index a0d54993edb3..97ee19f2cae0 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1207,12 +1207,10 @@ static int ghes_notify_hed(struct notifier_block *this,
unsigned long event,
int ret = NOTIFY_DONE;
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
- rcu_read_lock();
list_for_each_entry_rcu(ghes, &ghes_hed, list) {
if (!ghes_proc(ghes))
ret = NOTIFY_OK;
}
- rcu_read_unlock();
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
return ret;
--
2.34.1
