In the Linux kernel, list_for_each_entry_rcu() is used to traverse rcu protected list in reader side critical section. What happens if list_for_each_entry() is used instead? Does it cause problems?
Asked
Active
Viewed 63 times
0
-
Yes... yes it does. That is exactly why `list_for_each_entry_rcu` exists :') – Marco Bonelli Apr 27 '23 at 18:00
1 Answers
0
In some architectures CPUs can look through the next pointer early. Specially in case of ALPHA and SPARC CPUs. Hence list_for_each_entry_rcu() is needed which essentially put memory barriers to limit this behavior. However in writer side we can avoid list_for_each_entry_rcu() and use list_for_each_entry().
user16217248
- 3,119
- 19
- 19
- 37
MankPan
- 79
- 6
-
Does it cause problems in architectures like x86 or arm when using list_for_each_entry() in rcu reader side? – hdthky May 05 '23 at 06:31
-
Is there any guarantee that x86 / arm will behave same in future too? Presently, list_for_each_entry_rcu() differ from its ancestor on two grounds. 1. It includes call to __list_check_rcu() —> which will complain loudly if you are calling this API out of rcu_read_(un)lock(), provided lockdep is configured. 2. Has compiler only memory barrier READ_ONCE() except DEC Alpha. READ_ONCE behaviour can change in case of ARM when building with LTO. – MankPan May 06 '23 at 05:44