Lines Matching full:that
9 that make use of RCU. Violating any of the rules listed below will
10 result in the same sorts of problems that leaving out a locking primitive
17 performance measurements show that RCU is nonetheless the right
35 approach provides the same potential simplifications that garbage
54 information relating to itself that other tasks can read, there
55 by definition can be no bottleneck). Note that the definition
73 Please not that you *cannot* rely on code known to be built
86 any locks or atomic operations. This means that readers will
93 RCU-protected data structures that have been added to
99 locks (that are acquired by both readers and writers)
100 that guard per-element state. Of course, fields that
115 d. Carefully order the updates and the reads so that
124 a separate structure, so that the change may be made
134 accesses. The rcu_dereference() primitive ensures that
136 that the pointer points to. This really is necessary
142 Please note that compilers can also reorder code, and
144 just that. The rcu_dereference() primitive therefore also
152 as the list_for_each_entry_rcu(). Note that it is
155 primitives. This is particularly useful in code that
185 e. Updates must ensure that initialization of a given
186 structure happens before pointers to that structure are
188 when publicizing a pointer to a structure that can
193 If you need the callback to block, run that code in a workqueue
206 be restricted to rare configuration-change operations that would
214 Restructure your code so that it batches the updates, allowing
225 rcu_read_unlock(), (2) any pair of primitives that disables
227 rcu_read_unlock_bh(), or (3) any pair of primitives that disables
237 context switches, that is, from blocking. If the updater uses
242 must use anything that disables interrupts.
253 that this usage is safe is that readers can use anything that
267 primitive is that it automatically self-limits: if grace periods
290 the memory allocator, so that this wrapper function
304 here is that superuser already has lots of ways to crash
313 Note that although these primitives do take action to avoid memory
330 The reason that it is permissible to use RCU list-traversal
331 primitives when the update-side lock is held is that doing so
338 time that readers might be accessing that structure. In such
352 acquisition of that lock will result in deadlock as soon as
354 interrupting that acquisition's critical section.
357 the callback code simply wrappers around kfree(), so that this
358 is not an issue (or, more accurately, to the extent that it is
362 to safely access and/or modify that data structure.
364 Do not assume that RCU callbacks will be executed on the same
365 CPU that executed the corresponding call_rcu() or call_srcu().
367 callback pending, then that RCU callback will execute on some
378 Please note that if you don't need to sleep in read-side critical
386 "struct srcu_struct" that defines the scope of a given
392 calls that have been passed the same srcu_struct. This property
415 Note that rcu_assign_pointer() relates to SRCU just as it does to
423 that readers can follow that could be affected by the
428 is the caller's responsibility to guarantee that any subsequent
445 check that accesses to RCU-protected data
452 check that you don't pass the
454 grace period has elapsed since the last time that you
455 passed that same object to call_rcu() (or friends).
460 access that pointer without the services of one of the
463 These debugging aids can help you find problems that are
469 the last invocation and before unloading that module. Note that
473 Or even on the current CPU if that CPU recently went offline