From: "Paul E. McKenney" Add verbiage to an existing comment. Signed-off-by: Paul E. McKenney Signed-off-by: Andrew Morton --- kernel/srcu.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+) diff -puN kernel/srcu.c~srcu-3-rcu-variant-permitting-read-side-blocking-comments kernel/srcu.c --- a/kernel/srcu.c~srcu-3-rcu-variant-permitting-read-side-blocking-comments +++ a/kernel/srcu.c @@ -211,6 +211,25 @@ void synchronize_srcu(struct srcu_struct * More importantly, it also forces the corresponding SRCU read-side * critical sections to have also completed, and the corresponding * references to SRCU-protected data items to be dropped. + * + * Note: + * + * Despite what you might think at first glance, the + * preceding synchronize_sched() -must- be within the + * critical section ended by the following mutex_unlock(). + * Otherwise, a task taking the early exit can race + * with a srcu_read_unlock(), which might have executed + * just before the preceding srcu_readers_active() check, + * and whose CPU might have reordered the srcu_read_unlock() + * with the preceding critical section. In this case, there + * is nothing preventing the synchronize_sched() task that is + * taking the early exit from freeing a data structure that + * is still being referenced (out of order) by the task + * doing the srcu_read_unlock(). + * + * Alternatively, the comparison with "2" on the early exit + * could be changed to "3", but this increases synchronize_srcu() + * latency for bulk loads. So the current code is preferred. */ mutex_unlock(&sp->mutex); _