Here's another potential problem with the fast path approach. It's not
very serious, but you might want to keep it in mind.
The idea is that a reader can start up on one CPU and finish on another,
and a writer might see the finish event but not the start event. For
example:
Reader A enters the critical section on CPU 0 and starts
accessing the old data area.
Writer B updates the data pointer and starts executing
srcu_readers_active_idx() to check if the fast path can be
used. It sees per_cpu_ptr(0)->c[idx] == 1 because of
Reader A.
Reader C runs srcu_read_lock() on CPU 0, setting
per_cpu_ptr[0]->c[idx] to 2.
Reader C migrates to CPU 1 and leaves the critical section;
srcu_read_unlock() sets per_cpu_ptr(1)->c[idx] to -1.
Writer B finishes the cpu loop in srcu_readers_active_idx(),
seeing per_cpu_ptr(1)->c[idx] == -1. It computes sum =
1 + -1 == 0, takes the fast path, and exits immediately
from synchronize_srcu().
Writer B deallocates the old data area while Reader A is still
using it.
This requires two context switches to take place while the cpu loop in
srcu_readers_active_idx() runs, so perhaps it isn't realistic. Is it
worth worrying about?
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
