rcu_dereference() 반환값을 올바르게 다루는 법

Address/data dependency의 출발점

RCU의 정확성에는 address dependency와 data dependency를 보존하는 일이 매우 중요하다. `rcu_dereference()` 계열이 반환한 pointer는 해당 macro가 pointer를 load한 시점부터, 그 pointer로 나중 memory access의 주소를 계산하거나 store할 값을 계산하는 시점까지 dependency를 운반한다.

일반적인 역참조 `*`, field 선택 `->`, 대입 `=`, 주소 연산 `&`, cast, 상수 덧셈과 뺄셈은 dependency를 자연스럽게 보존한다. 그러나 compiler는 dependency를 언어 수준의 ordering으로 완전히 이해하지 않으므로 특정 변환이 dependency를 없앨 수 있다.

RCU-protected pointer는 반드시 `rcu_dereference()` 계열로 load해야 한다. 그렇지 않으면 `CONFIG_PROVE_RCU` 경고뿐 아니라 compiler의 재로딩으로 같은 논리 pointer가 두 값으로 사용되거나, DEC Alpha에서 pointer 게시 전 초기화보다 오래된 데이터를 읽는 memory corruption이 생길 수 있다. 최근 kernel에서는 `READ_ONCE()`도 Alpha의 관련 재정렬을 막는다.

`rcu_dereference()`의 volatile cast는 compiler가 반환 pointer의 정확한 값을 추론하기 어렵게 한다. 이후 절처럼 compiler가 가능한 pointer 값을 모두 알게 되면 비교 결과로 주소를 상수화해 dependency를 제거할 수 있기 때문이다.

.. _rcu_dereference_doc:

PROPER CARE AND FEEDING OF RETURN VALUES FROM rcu_dereference()
===============================================================

Proper care and feeding of address and data dependencies is critically
important to correct use of things like RCU.  To this end, the pointers
returned from the rcu_dereference() family of primitives carry address and
data dependencies.  These dependencies extend from the rcu_dereference()
macro's load of the pointer to the later use of that pointer to compute
either the address of a later memory access (representing an address
dependency) or the value written by a later memory access (representing
a data dependency).

Most of the time, these dependencies are preserved, permitting you to
freely use values from rcu_dereference().  For example, dereferencing
(prefix "*"), field selection ("->"), assignment ("="), address-of
("&"), casts, and addition or subtraction of constants all work quite
naturally and safely.  However, because current compilers do not take
either address or data dependencies into account it is still possible
to get into trouble.

Follow these rules to preserve the address and data dependencies emanating
from your calls to rcu_dereference() and friends, thus keeping your RCU
readers working properly:

-        You must use one of the rcu_dereference() family of primitives
        to load an RCU-protected pointer, otherwise CONFIG_PROVE_RCU
        will complain.  Worse yet, your code can see random memory-corruption
        bugs due to games that compilers and DEC Alpha can play.
        Without one of the rcu_dereference() primitives, compilers
        can reload the value, and won't your code have fun with two
        different values for a single pointer!  Without rcu_dereference(),
        DEC Alpha can load a pointer, dereference that pointer, and
        return data preceding initialization that preceded the store
        of the pointer.  (As noted later, in recent kernels READ_ONCE()
        also prevents DEC Alpha from playing these tricks.)

        In addition, the volatile cast in rcu_dereference() prevents the
        compiler from deducing the resulting pointer value.  Please see
        the section entitled "EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH"
        for an example where the compiler can in fact deduce the exact
        value of the pointer, and thus cause misordering.

-        In the special case where data is added but is never removed
        while readers are accessing the structure, READ_ONCE() may be used
        instead of rcu_dereference().  In this case, use of READ_ONCE()
        takes on the role of the lockless_dereference() primitive that
        was removed in v4.15.

READ_ONCE, integer cast와 산술 규칙

Reader가 접근하는 동안 자료가 추가되기만 하고 제거되지 않는 특별한 구조에서는 `rcu_dereference()` 대신 `READ_ONCE()`를 사용할 수 있다. 이 용법은 v4.15에서 제거된 `lockless_dereference()`의 역할을 이어받는다.

`rcu_dereference()`는 pointer 값에만 사용해야 한다. Compiler가 integer 연산을 지나며 값을 추론하기 너무 쉽기 때문이다. 제한된 예외로 pointer를 잠시 `uintptr_t`로 cast해 정렬로 반드시 0인 low-order bit를 set/clear하거나 classic buddy allocator처럼 XOR로 pointer를 변환할 수 있다. 곧바로 다시 pointer로 cast해야 하며 `char *`처럼 정렬 보장이 약한 pointer에는 일반적으로 쓸 수 없다.

산술이 원래 값을 상쇄하면 dependency도 사라진다. 예를 들어 `x - (uintptr_t)x`는 compiler가 0으로 치환할 수 있다. 반면 `p+a-b`에서 우연히 `a==b`여도 식의 표현이 여전히 `p`에 의존하면 dependency가 유지된다.

RCU로 JIT 함수 수명을 보호하고 `rcu_dereference()`에서 얻은 주소를 호출한다면, old JIT 코드와 같은 memory를 재사용하는 시스템에서 instruction cache를 hardware 수준으로 flush해야 할 수 있다. RCU의 data ordering이 instruction cache coherence를 자동으로 대신하지는 않는다.

-        You are only permitted to use rcu_dereference() on pointer values.
        The compiler simply knows too much about integral values to
        trust it to carry dependencies through integer operations.
        There are a very few exceptions, namely that you can temporarily
        cast the pointer to uintptr_t in order to:

        -        Set bits and clear bits down in the must-be-zero low-order
                bits of that pointer.  This clearly means that the pointer
                must have alignment constraints, for example, this does
                *not* work in general for char* pointers.

        -        XOR bits to translate pointers, as is done in some
                classic buddy-allocator algorithms.

        It is important to cast the value back to pointer before
        doing much of anything else with it.

-        Avoid cancellation when using the "+" and "-" infix arithmetic
        operators.  For example, for a given variable "x", avoid
        "(x-(uintptr_t)x)" for char* pointers.        The compiler is within its
        rights to substitute zero for this sort of expression, so that
        subsequent accesses no longer depend on the rcu_dereference(),
        again possibly resulting in bugs due to misordering.

        Of course, if "p" is a pointer from rcu_dereference(), and "a"
        and "b" are integers that happen to be equal, the expression
        "p+a-b" is safe because its value still necessarily depends on
        the rcu_dereference(), thus maintaining proper ordering.

-        If you are using RCU to protect JITed functions, so that the
        "()" function-invocation operator is applied to a value obtained
        (directly or indirectly) from rcu_dereference(), you may need to
        interact directly with the hardware to flush instruction caches.
        This issue arises on some systems when a newly JITed function is
        using the same memory that was used by an earlier JITed function.

-        Do not use the results from relational operators ("==", "!=",
        ">", ">=", "<", or "<=") when dereferencing.  For example,
        the following (quite strange) code is buggy::

                int *p;
                int *q;

                ...

                p = rcu_dereference(gp)
                q = &global_q;
                q += p > &oom_p;
                r1 = *q;  /* BUGGY!!! */

        As before, the reason this is buggy is that relational operators
        are often compiled using branches.  And as before, although
        weak-memory machines such as ARM or PowerPC do order stores

관계 연산과 non-NULL pointer 비교

관계 연산 `==`, `!=`, `>`, `>=`, `<`, `<=`의 결과로 역참조 주소를 선택하면 안 된다. 관계 연산은 branch로 compile되는 경우가 많고 ARM이나 PowerPC는 branch 뒤 store는 ordering할 수 있어도 load를 speculate할 수 있다. 예제의 `q += p > &oom_p; r1 = *q`는 따라서 잘못이다.

특히 `rcu_dereference()` pointer를 non-NULL 상수 주소와 비교한 뒤 역참조하면 compiler가 비교가 참인 branch에서 pointer를 그 상수 주소로 바꿀 수 있다. `p == &default_struct` 뒤 `p->a`는 `default_struct.a`로 변환되고 load가 accessor보다 앞서 speculate될 수 있다.

NULL 비교는 안전하다. NULL이면 역참조하면 안 되고 non-NULL branch에서는 compiler가 실제 주소를 알 수 없기 때문이다. 비교 뒤 pointer를 전혀 역참조하지 않는 경우도 안전하며, reader 밖에서 값만 비교한다면 `rcu_access_pointer()`를 변수에 저장하지 않고 직접 검사하는 편이 낫다.

비교 대상 memory가 compile time, boot time, module init, kthread 생성 전, 이전 lock 획득 전, `mod_timer()` 전처럼 충분히 오래전에 초기화되어 이후 ordering이 중요하지 않다면 안전할 수 있다. 두 pointer가 모두 `rcu_dereference()`에서 왔거나, 비교 뒤 access가 모두 store여서 올바른 control dependency가 있는 경우도 가능하다.

두 pointer가 같지 않고 compiler가 첫 pointer 값을 추론할 정보가 부족하면 보통 안전하다. 하지만 가능한 값이 둘뿐이라면 not-equal 결과가 나머지 하나를 정확히 알려 주므로 안전하지 않다. Profile feedback 기반 value speculation은 dependency를 설계상 깨므로 꺼야 한다. Branch-prediction hardware를 활용한 speculation은 x86 같은 strong-order 시스템에서는 가능하지만 ARM/Power에는 안전하지 않다.

        after such branches, but can speculate loads, which can again
        result in misordering bugs.

-        Be very careful about comparing pointers obtained from
        rcu_dereference() against non-NULL values.  As Linus Torvalds
        explained, if the two pointers are equal, the compiler could
        substitute the pointer you are comparing against for the pointer
        obtained from rcu_dereference().  For example::

                p = rcu_dereference(gp);
                if (p == &default_struct)
                        do_default(p->a);

        Because the compiler now knows that the value of "p" is exactly
        the address of the variable "default_struct", it is free to
        transform this code into the following::

                p = rcu_dereference(gp);
                if (p == &default_struct)
                        do_default(default_struct.a);

        On ARM and Power hardware, the load from "default_struct.a"
        can now be speculated, such that it might happen before the
        rcu_dereference().  This could result in bugs due to misordering.

        However, comparisons are OK in the following cases:

        -        The comparison was against the NULL pointer.  If the
                compiler knows that the pointer is NULL, you had better
                not be dereferencing it anyway.  If the comparison is
                non-equal, the compiler is none the wiser.  Therefore,
                it is safe to compare pointers from rcu_dereference()
                against NULL pointers.

        -        The pointer is never dereferenced after being compared.
                Since there are no subsequent dereferences, the compiler
                cannot use anything it learned from the comparison
                to reorder the non-existent subsequent dereferences.
                This sort of comparison occurs frequently when scanning
                RCU-protected circular linked lists.

                Note that if the pointer comparison is done outside
                of an RCU read-side critical section, and the pointer
                is never dereferenced, rcu_access_pointer() should be
                used in place of rcu_dereference().  In most cases,
                it is best to avoid accidental dereferences by testing
                the rcu_access_pointer() return value directly, without
                assigning it to a variable.

                Within an RCU read-side critical section, there is little
                reason to use rcu_access_pointer().

        -        The comparison is against a pointer that references memory
                that was initialized "a long time ago."  The reason
                this is safe is that even if misordering occurs, the
                misordering will not affect the accesses that follow
                the comparison.  So exactly how long ago is "a long
                time ago"?  Here are some possibilities:

                -        Compile time.

                -        Boot time.

                -        Module-init time for module code.

                -        Prior to kthread creation for kthread code.

                -        During some prior acquisition of the lock that
                        we now hold.

                -        Before mod_timer() time for a timer handler.

                There are many other possibilities involving the Linux
                kernel's wide array of primitives that cause code to
                be invoked at a later time.

        -        The pointer being compared against also came from
                rcu_dereference().  In this case, both pointers depend
                on one rcu_dereference() or another, so you get proper
                ordering either way.

                That said, this situation can make certain RCU usage
                bugs more likely to happen.  Which can be a good thing,
                at least if they happen during testing.  An example
                of such an RCU usage bug is shown in the section titled
                "EXAMPLE OF AMPLIFIED RCU-USAGE BUG".

        -        All of the accesses following the comparison are stores,
                so that a control dependency preserves the needed ordering.
                That said, it is easy to get control dependencies wrong.
                Please see the "CONTROL DEPENDENCIES" section of
                Documentation/memory-barriers.txt for more details.

        -        The pointers are not equal *and* the compiler does
                not have enough information to deduce the value of the
                pointer.  Note that the volatile cast in rcu_dereference()
                will normally prevent the compiler from knowing too much.

                However, please note that if the compiler knows that the
                pointer takes on only one of two values, a not-equal
                comparison will provide exactly the information that the
                compiler needs to deduce the value of the pointer.

-        Disable any value-speculation optimizations that your compiler
        might provide, especially if you are making use of feedback-based
        optimizations that take data collected from prior runs.  Such
        value-speculation optimizations reorder operations by design.

        There is one exception to this rule:  Value-speculation
        optimizations that leverage the branch-prediction hardware are
        safe on strongly ordered systems (such as x86), but not on weakly
        ordered systems (such as ARM or Power).  Choose your compiler
        command-line options wisely!

비일관 reader bug가 증폭되는 예

RCU updater는 reader와 동시에 실행하므로 reader가 stale하거나 서로 일관되지 않은 필드 값을 보는 것은 기본적으로 허용된다. 예제의 updater는 새 `struct foo`에 `b=43`, `c=44`를 쓰고 `gp1`으로 게시한 뒤 같은 객체를 `b=143`, `c=144`로 바꾸고 `gp2`로 게시한다.

Reader가 먼저 `gp2`를 읽어 `r1=p->b`에서 143을 얻고, 이어 `gp1`을 읽어 `p==q`를 확인한 뒤 `p->c`를 읽어도 weak-order 시스템에서는 44가 나올 수 있다. Compiler가 `q->c`와 `p->c`를 같다고 판단하는 변환뿐 아니라, 두 load 사이 updater가 다시 실행되는 정상적인 동시성만으로도 같은 결과가 가능하다.

일관된 view가 필요하면 별도 lock을 사용한다. 예제는 `struct foo`에 spinlock을 넣고 updater가 필드 묶음을 lock 아래 변경하며, reader도 `p->lock` 아래 `b`와 `c`를 읽는다. `p!=q`이면 `q->lock`도 잡아 해당 객체의 `c`를 안정시킨다.

RCU는 객체의 존재와 publish ordering을 제공하지만 같은 객체의 여러 시점 필드를 atomic snapshot으로 만들지 않는다. Freshness와 consistency가 필요하면 그 요구에 맞는 lock, sequence counter 또는 copy-replace 설계를 함께 사용해야 한다.

EXAMPLE OF AMPLIFIED RCU-USAGE BUG
----------------------------------

Because updaters can run concurrently with RCU readers, RCU readers can
see stale and/or inconsistent values.  If RCU readers need fresh or
consistent values, which they sometimes do, they need to take proper
precautions.  To see this, consider the following code fragment::

        struct foo {
                int a;
                int b;
                int c;
        };
        struct foo *gp1;
        struct foo *gp2;

        void updater(void)
        {
                struct foo *p;

                p = kmalloc(...);
                if (p == NULL)
                        deal_with_it();
                p->a = 42;  /* Each field in its own cache line. */
                p->b = 43;
                p->c = 44;
                rcu_assign_pointer(gp1, p);
                p->b = 143;
                p->c = 144;
                rcu_assign_pointer(gp2, p);
        }

        void reader(void)
        {
                struct foo *p;
                struct foo *q;
                int r1, r2;

                rcu_read_lock();
                p = rcu_dereference(gp2);
                if (p == NULL)
                        return;
                r1 = p->b;  /* Guaranteed to get 143. */
                q = rcu_dereference(gp1);  /* Guaranteed non-NULL. */
                if (p == q) {
                        /* The compiler decides that q->c is same as p->c. */
                        r2 = p->c; /* Could get 44 on weakly order system. */
                } else {
                        r2 = p->c - r1; /* Unconditional access to p->c. */
                }
                rcu_read_unlock();
                do_something_with(r1, r2);
        }

You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
but you should not be.  After all, the updater might have been invoked
a second time between the time reader() loaded into "r1" and the time
that it loaded into "r2".  The fact that this same result can occur due
to some reordering from the compiler and CPUs is beside the point.

But suppose that the reader needs a consistent view?

Then one approach is to use locking, for example, as follows::

        struct foo {
                int a;
                int b;
                int c;
                spinlock_t lock;
        };
        struct foo *gp1;
        struct foo *gp2;

        void updater(void)
        {
                struct foo *p;

                p = kmalloc(...);
                if (p == NULL)
                        deal_with_it();
                spin_lock(&p->lock);
                p->a = 42;  /* Each field in its own cache line. */
                p->b = 43;
                p->c = 44;
                spin_unlock(&p->lock);
                rcu_assign_pointer(gp1, p);
                spin_lock(&p->lock);
                p->b = 143;
                p->c = 144;
                spin_unlock(&p->lock);
                rcu_assign_pointer(gp2, p);
        }

        void reader(void)
        {
                struct foo *p;
                struct foo *q;
                int r1, r2;

                rcu_read_lock();
                p = rcu_dereference(gp2);
                if (p == NULL)
                        return;
                spin_lock(&p->lock);
                r1 = p->b;  /* Guaranteed to get 143. */
                q = rcu_dereference(gp1);  /* Guaranteed non-NULL. */
                if (p == q) {
                        /* The compiler decides that q->c is same as p->c. */
                        r2 = p->c; /* Locking guarantees r2 == 144. */
                } else {
                        spin_lock(&q->lock);
                        r2 = q->c - r1;
                        spin_unlock(&q->lock);
                }
                rcu_read_unlock();
                spin_unlock(&p->lock);
                do_something_with(r1, r2);
        }

As always, use the right tool for the job!

Compiler가 pointer 값을 너무 많이 아는 경우

평범한 상황에서는 `rcu_dereference()`의 volatile cast가 compiler의 pointer 값 추론을 방해한다. 하지만 accessor를 생략하고 translation unit 안에서 `gp`의 모든 store가 보이면 compiler는 가능한 값을 정확히 알 수 있다.

예제의 static `gp`는 처음 `&variable1`이고 유일한 store가 `rcu_assign_pointer(gp, &variable2)`다. Reader가 `p=gp` 뒤 `p==&variable1`을 검사하면 compiler는 true branch의 `p`가 `variable1`, false branch의 `p`가 `variable2`라고 확정한다.

그 결과 반환 load가 `gp` load와 무관한 상수 객체 access로 바뀌어 ordering이 사라지고, weak-order 시스템에서 `variable2.b`의 초기화 전 쓰레기 값을 읽을 수 있다. 단순 `barrier()`만으로는 RCU subscription dependency를 대신하지 못한다.

반환 pointer를 역참조할 예정이라면 `rcu_dereference()`는 선택 사항이 아니다. Accessor는 hardware ordering뿐 아니라 compiler가 load를 발명하거나 상수화하는 것을 제한한다.

EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH
-----------------------------------------

If a pointer obtained from rcu_dereference() compares not-equal to some
other pointer, the compiler normally has no clue what the value of the
first pointer might be.  This lack of knowledge prevents the compiler
from carrying out optimizations that otherwise might destroy the ordering
guarantees that RCU depends on.  And the volatile cast in rcu_dereference()
should prevent the compiler from guessing the value.

But without rcu_dereference(), the compiler knows more than you might
expect.  Consider the following code fragment::

        struct foo {
                int a;
                int b;
        };
        static struct foo variable1;
        static struct foo variable2;
        static struct foo *gp = &variable1;

        void updater(void)
        {
                initialize_foo(&variable2);
                rcu_assign_pointer(gp, &variable2);
                /*
                 * The above is the only store to gp in this translation unit,
                 * and the address of gp is not exported in any way.
                 */
        }

        int reader(void)
        {
                struct foo *p;

                p = gp;
                barrier();
                if (p == &variable1)
                        return p->a; /* Must be variable1.a. */
                else
                        return p->b; /* Must be variable2.b. */
        }

Because the compiler can see all stores to "gp", it knows that the only
possible values of "gp" are "variable1" on the one hand and "variable2"
on the other.  The comparison in reader() therefore tells the compiler
the exact value of "p" even in the not-equals case.  This allows the
compiler to make the return values independent of the load from "gp",
in turn destroying the ordering between this load and the loads of the
return values.  This can result in "p->b" returning pre-initialization
garbage values on weakly ordered systems.

In short, rcu_dereference() is *not* optional when you are going to
dereference the resulting pointer.

어떤 rcu_dereference() 계열을 쓸 것인가

`rcu_dereference_raw()`와 조건을 상수 1로 둔 `_check()` 또는 `_protected()` 사용은 피해야 한다. 보호 관계를 검증할 기회를 없애기 때문이다.

일반 RCU reader 안이어야 하는 access는 `rcu_dereference()`를 쓴다. 통합된 RCU flavor에서는 `rcu_read_lock()`뿐 아니라 bottom half, interrupt, preemption을 disable하는 구간과 spinlock critical section도 암묵적 RCU reader다. `CONFIG_PREEMPT_RT=y`에서 spinlock이 preemptible이어도 이 의미는 유지된다.

RCU reader 또는 `my_lock` 아래에서 호출될 수 있으면 `rcu_dereference_check(..., lockdep_is_held(&my_lock))`를 쓴다. `my_lock`이나 `your_lock` 중 하나면 조건을 OR로 합친다. Update-side에서 항상 `my_lock`이 보호한다면 `rcu_dereference_protected()`가 맞다.

보호를 caller가 제공해 현재 함수가 표현할 수 없거나 수많은 lock/reference counter 중 하나가 보호하는 드문 data-locking 설계에서는 `rcu_dereference_raw()`를 쓸 수 있다. 조건이 지나치게 복잡하다면 먼저 synchronization 설계를 단순화할 수 있는지 검토해야 한다.

WHICH MEMBER OF THE rcu_dereference() FAMILY SHOULD YOU USE?
------------------------------------------------------------

First, please avoid using rcu_dereference_raw() and also please avoid
using rcu_dereference_check() and rcu_dereference_protected() with a
second argument with a constant value of 1 (or true, for that matter).
With that caution out of the way, here is some guidance for which
member of the rcu_dereference() to use in various situations:

1.        If the access needs to be within an RCU read-side critical
        section, use rcu_dereference().  With the new consolidated
        RCU flavors, an RCU read-side critical section is entered
        using rcu_read_lock(), anything that disables bottom halves,
        anything that disables interrupts, or anything that disables
        preemption.  Please note that spinlock critical sections
        are also implied RCU read-side critical sections, even when
        they are preemptible, as they are in kernels built with
        CONFIG_PREEMPT_RT=y.

2.        If the access might be within an RCU read-side critical section
        on the one hand, or protected by (say) my_lock on the other,
        use rcu_dereference_check(), for example::

                p1 = rcu_dereference_check(p->rcu_protected_pointer,
                                           lockdep_is_held(&my_lock));


3.        If the access might be within an RCU read-side critical section
        on the one hand, or protected by either my_lock or your_lock on
        the other, again use rcu_dereference_check(), for example::

                p1 = rcu_dereference_check(p->rcu_protected_pointer,
                                           lockdep_is_held(&my_lock) ||
                                           lockdep_is_held(&your_lock));

4.        If the access is on the update side, so that it is always protected
        by my_lock, use rcu_dereference_protected()::

                p1 = rcu_dereference_protected(p->rcu_protected_pointer,
                                               lockdep_is_held(&my_lock));

        This can be extended to handle multiple locks as in #3 above,
        and both can be extended to check other conditions as well.

5.        If the protection is supplied by the caller, and is thus unknown
        to this code, that is the rare case when rcu_dereference_raw()
        is appropriate.  In addition, rcu_dereference_raw() might be
        appropriate when the lockdep expression would be excessively
        complex, except that a better approach in that case might be to
        take a long hard look at your synchronization design.  Still,
        there are data-locking cases where any one of a very large number
        of locks or reference counters suffices to protect the pointer,
        so rcu_dereference_raw() does have its place.

        However, its place is probably quite a bit smaller than one
        might expect given the number of uses in the current kernel.
        Ditto for its synonym, rcu_dereference_check( ... , 1), and
        its close relative, rcu_dereference_protected(... , 1).

Sparse의 __rcu pointer 검사

Sparse는 RCU pointer를 일반 load로 접근하는 코드를 찾아 compiler의 invented load와 load tearing 위험을 줄인다. `p = q->rcu_protected_pointer` 뒤 `p->a`, `p->b`를 읽는 코드는 register pressure가 높을 때 compiler가 `p`를 없애고 field마다 `q->rcu_protected_pointer`를 다시 읽도록 바꿀 수 있다.

두 load 사이 pointer가 바뀌면 서로 다른 객체의 필드를 사용한다. Load tearing이 있으면 두 pointer bit를 섞은 존재하지 않는 주소를 역참조할 수도 있다. `p = rcu_dereference(q->rcu_protected_pointer)`로 한 번 load하면 이러한 변환과 ordering 문제를 막는다.

Review만으로 찾기 어려우므로 declaration을 `struct foo __rcu *rcu_protected_pointer`처럼 `__rcu`로 표시한다. Sparse는 이 pointer를 직접 접근하면 경고하고, 반대로 `__rcu`가 아닌 pointer를 `rcu_dereference()` 계열로 접근해도 경고한다.

`__rcu`는 opt-in이다. 프로젝트가 이 annotation을 쓰지 않기로 했다면 관련 sparse warning을 무시할 수 있지만, 사용한다면 pointer 선언과 accessor를 일관되게 맞춰야 한다.

SPARSE CHECKING OF RCU-PROTECTED POINTERS
-----------------------------------------

The sparse static-analysis tool checks for non-RCU access to RCU-protected
pointers, which can result in "interesting" bugs due to compiler
optimizations involving invented loads and perhaps also load tearing.
For example, suppose someone mistakenly does something like this::

        p = q->rcu_protected_pointer;
        do_something_with(p->a);
        do_something_else_with(p->b);

If register pressure is high, the compiler might optimize "p" out
of existence, transforming the code to something like this::

        do_something_with(q->rcu_protected_pointer->a);
        do_something_else_with(q->rcu_protected_pointer->b);

This could fatally disappoint your code if q->rcu_protected_pointer
changed in the meantime.  Nor is this a theoretical problem:  Exactly
this sort of bug cost Paul E. McKenney (and several of his innocent
colleagues) a three-day weekend back in the early 1990s.

Load tearing could of course result in dereferencing a mashup of a pair
of pointers, which also might fatally disappoint your code.

These problems could have been avoided simply by making the code instead
read as follows::

        p = rcu_dereference(q->rcu_protected_pointer);
        do_something_with(p->a);
        do_something_else_with(p->b);

Unfortunately, these sorts of bugs can be extremely hard to spot during
review.  This is where the sparse tool comes into play, along with the
"__rcu" marker.  If you mark a pointer declaration, whether in a structure
or as a formal parameter, with "__rcu", which tells sparse to complain if
this pointer is accessed directly.  It will also cause sparse to complain
if a pointer not marked with "__rcu" is accessed using rcu_dereference()
and friends.  For example, ->rcu_protected_pointer might be declared as
follows::

        struct foo __rcu *rcu_protected_pointer;

Use of "__rcu" is opt-in.  If you choose not to use it, then you should
ignore the sparse warnings.