Skip to content

Commit 4385001

Browse files
committed
doc: Further updates to RCU's lockdep.rst
This commit wordsmiths RCU's lockdep.rst. Signed-off-by: Paul E. McKenney <[email protected]>
1 parent 1b929c0 commit 4385001

File tree

1 file changed

+6
-7
lines changed

1 file changed

+6
-7
lines changed

Documentation/RCU/lockdep.rst

Lines changed: 6 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -69,9 +69,8 @@ checking of rcu_dereference() primitives:
6969
value of the pointer itself, for example, against NULL.
7070

7171
The rcu_dereference_check() check expression can be any boolean
72-
expression, but would normally include a lockdep expression. However,
73-
any boolean expression can be used. For a moderately ornate example,
74-
consider the following::
72+
expression, but would normally include a lockdep expression. For a
73+
moderately ornate example, consider the following::
7574

7675
file = rcu_dereference_check(fdt->fd[fd],
7776
lockdep_is_held(&files->file_lock) ||
@@ -97,10 +96,10 @@ code, it could instead be written as follows::
9796
atomic_read(&files->count) == 1);
9897

9998
This would verify cases #2 and #3 above, and furthermore lockdep would
100-
complain if this was used in an RCU read-side critical section unless one
101-
of these two cases held. Because rcu_dereference_protected() omits all
102-
barriers and compiler constraints, it generates better code than do the
103-
other flavors of rcu_dereference(). On the other hand, it is illegal
99+
complain even if this was used in an RCU read-side critical section unless
100+
one of these two cases held. Because rcu_dereference_protected() omits
101+
all barriers and compiler constraints, it generates better code than do
102+
the other flavors of rcu_dereference(). On the other hand, it is illegal
104103
to use rcu_dereference_protected() if either the RCU-protected pointer
105104
or the RCU-protected data that it points to can change concurrently.
106105

0 commit comments

Comments
 (0)