€•
      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ'/translations/zh_CN/RCU/rcu_dereference”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ'/translations/zh_TW/RCU/rcu_dereference”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ'/translations/it_IT/RCU/rcu_dereference”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ'/translations/ja_JP/RCU/rcu_dereference”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ'/translations/ko_KR/RCU/rcu_dereference”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒPortuguese (Brazilian)”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ'/translations/pt_BR/RCU/rcu_dereference”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh–sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ'/translations/sp_SP/RCU/rcu_dereference”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒtarget”“”)”}”(hŒ.. _rcu_dereference_doc:”h]”h}”(h]”h ]”h"]”h$]”h&]”Œrefid”Œrcu-dereference-doc”uh1hµh´Khhh²hh³ŒA/var/lib/git/docbuild/linux/Documentation/RCU/rcu_dereference.rst”ubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒ?PROPER CARE AND FEEDING OF RETURN VALUES FROM rcu_dereference()”h]”hŒ?PROPER CARE AND FEEDING OF RETURN VALUES FROM rcu_dereference()”…””}”(hhËh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhhÆh²hh³hÃh´KubhŒ	paragraph”“”)”}”(hX  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).”h]”hX  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).”…””}”(hhÛh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KhhÆh²hubhÚ)”}”(hXµ  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.”h]”hXÅ  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.”…””}”(hhéh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KhhÆh²hubhÚ)”}”(hŒ¬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:”h]”hŒ¬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:”…””}”(hh÷h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KhhÆh²hubhŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hXÖ  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.
”h]”(hÚ)”}”(hX¡  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.)”h]”hX£  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.)”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Khj  ubhÚ)”}”(hX2  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.”h]”hX6  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.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K'hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  h²hh³hÃh´Nubj  )”}”(hX  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.
”h]”hÚ)”}”(hX  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.”h]”hX  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.”…””}”(hj6  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K-hj2  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  h²hh³hÃh´Nubj  )”}”(hXæ  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.
”h]”(hÚ)”}”(hX%  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:”h]”hX%  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:”…””}”(hjN  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K3hjJ  ubj  )”}”(hhh]”(j  )”}”(hŒØ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.
”h]”hÚ)”}”(hŒ×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.”h]”(hŒ®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
”…””}”(hjc  h²hh³Nh´NubhŒemphasis”“”)”}”(hŒ*not*”h]”hŒnot”…””}”(hjm  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjc  ubhŒ$ work in general for char* pointers.”…””}”(hjc  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K9hj_  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj\  ubj  )”}”(hŒWXOR bits to translate pointers, as is done in some
classic buddy-allocator algorithms.
”h]”hÚ)”}”(hŒVXOR bits to translate pointers, as is done in some
classic buddy-allocator algorithms.”h]”hŒVXOR bits to translate pointers, as is done in some
classic buddy-allocator algorithms.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K>hj‹  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj\  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1j  h³hÃh´K9hjJ  ubhÚ)”}”(hŒ]It is important to cast the value back to pointer before
doing much of anything else with it.”h]”hŒ]It is important to cast the value back to pointer before
doing much of anything else with it.”…””}”(hj«  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KAhjJ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  h²hh³hÃh´Nubj  )”}”(hXc  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.
”h]”(hÚ)”}”(hXm  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.”h]”hX}  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.”…””}”(hjÃ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KDhj¿  ubhÚ)”}”(hŒó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.”h]”hX  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.”…””}”(hjÑ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KKhj¿  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  h²hh³hÃh´Nubj  )”}”(hXƒ  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.
”h]”hÚ)”}”(hX‚  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.”h]”hX†  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.”…””}”(hjé  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KPhjå  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  h²hh³hÃh´Nubj  )”}”(hX[  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
after such branches, but can speculate loads, which can again
result in misordering bugs.
”h]”(hÚ)”}”(hŒ¦Do not use the results from relational operators ("==", "!=",
">", ">=", "<", or "<=") when dereferencing.  For example,
the following (quite strange) code is buggy::”h]”hŒ½Do not use the results from relational operators (â€œ==â€, â€œ!=â€,
â€œ>â€, â€œ>=â€, â€œ<â€, or â€œ<=â€) when dereferencing.  For example,
the following (quite strange) code is buggy:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KWhjý  ubhŒliteral_block”“”)”}”(hŒfint *p;
int *q;

...

p = rcu_dereference(gp)
q = &global_q;
q += p > &oom_p;
r1 = *q;  /* BUGGY!!! */”h]”hŒfint *p;
int *q;

...

p = rcu_dereference(gp)
q = &global_q;
q += p > &oom_p;
r1 = *q;  /* BUGGY!!! */”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1j  h³hÃh´K[hjý  ubhÚ)”}”(hX  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
after such branches, but can speculate loads, which can again
result in misordering bugs.”h]”hX  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
after such branches, but can speculate loads, which can again
result in misordering bugs.”…””}”(hj!  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Kehjý  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  h²hh³hÃh´Nubj  )”}”(hXÚ  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.
”h]”(hÚ)”}”(hX"  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::”h]”hX!  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:”…””}”(hj9  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Kkhj5  ubj  )”}”(hŒLp = rcu_dereference(gp);
if (p == &default_struct)
        do_default(p->a);”h]”hŒLp = rcu_dereference(gp);
if (p == &default_struct)
        do_default(p->a);”…””}”hjG  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´Kqhj5  ubhÚ)”}”(hŒ¤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::”h]”hŒ«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:”…””}”(hjU  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Kuhj5  ubj  )”}”(hŒXp = rcu_dereference(gp);
if (p == &default_struct)
        do_default(default_struct.a);”h]”hŒXp = rcu_dereference(gp);
if (p == &default_struct)
        do_default(default_struct.a);”…””}”hjc  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´Kyhj5  ubhÚ)”}”(hŒ¹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.”h]”hŒ½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.”…””}”(hjq  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K}hj5  ubhÚ)”}”(hŒ3However, comparisons are OK in the following cases:”h]”hŒ3However, comparisons are OK in the following cases:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Khj5  ubj  )”}”(hhh]”(j  )”}”(hX'  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.
”h]”hÚ)”}”(hX&  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.”h]”hX&  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.”…””}”(hj”  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Kƒhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hXõ  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().
”h]”(hÚ)”}”(hX5  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.”h]”hX5  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.”…””}”(hj¬  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KŠhj¨  ubhÚ)”}”(hX^  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.”h]”hX^  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.”…””}”(hjº  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K‘hj¨  ubhÚ)”}”(hŒ]Within an RCU read-side critical section, there is little
reason to use rcu_access_pointer().”h]”hŒ]Within an RCU read-side critical section, there is little
reason to use rcu_access_pointer().”…””}”(hjÈ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K™hj¨  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hXÍ  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.
”h]”(hÚ)”}”(hX5  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:”h]”hX=  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:”…””}”(hjà  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KœhjÜ  ubj  )”}”(hhh]”(j  )”}”(hŒCompile time.
”h]”hÚ)”}”(hŒCompile time.”h]”hŒCompile time.”…””}”(hjõ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K£hjñ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjî  ubj  )”}”(hŒBoot time.
”h]”hÚ)”}”(hŒ
Boot time.”h]”hŒ
Boot time.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K¥hj	  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjî  ubj  )”}”(hŒ"Module-init time for module code.
”h]”hÚ)”}”(hŒ!Module-init time for module code.”h]”hŒ!Module-init time for module code.”…””}”(hj%  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K§hj!  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjî  ubj  )”}”(hŒ,Prior to kthread creation for kthread code.
”h]”hÚ)”}”(hŒ+Prior to kthread creation for kthread code.”h]”hŒ+Prior to kthread creation for kthread code.”…””}”(hj=  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K©hj9  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjî  ubj  )”}”(hŒ<During some prior acquisition of the lock that
we now hold.
”h]”hÚ)”}”(hŒ;During some prior acquisition of the lock that
we now hold.”h]”hŒ;During some prior acquisition of the lock that
we now hold.”…””}”(hjU  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K«hjQ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjî  ubj  )”}”(hŒ-Before mod_timer() time for a timer handler.
”h]”hÚ)”}”(hŒ,Before mod_timer() time for a timer handler.”h]”hŒ,Before mod_timer() time for a timer handler.”…””}”(hjm  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K®hji  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjî  ubeh}”(h]”h ]”h"]”h$]”h&]”j©  jª  uh1j  h³hÃh´K£hjÜ  ubhÚ)”}”(hŒ‡There are many other possibilities involving the Linux
kernel's wide array of primitives that cause code to
be invoked at a later time.”h]”hŒ‰There are many other possibilities involving the Linux
kernelâ€™s wide array of primitives that cause code to
be invoked at a later time.”…””}”(hj‡  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K°hjÜ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hXµ  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".
”h]”(hÚ)”}”(hŒ´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.”h]”hŒ´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.”…””}”(hjŸ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K´hj›  ubhÚ)”}”(hŒþ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".”h]”hX  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â€.”…””}”(hj­  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K¹hj›  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hX  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.
”h]”hÚ)”}”(hX  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.”h]”hX  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.”…””}”(hjÅ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´K¿hjÁ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubj  )”}”(hXº  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.
”h]”(hÚ)”}”(hŒÞ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.”h]”(hŒThe pointers are not equal ”…””}”(hjÝ  h²hh³Nh´Nubjl  )”}”(hŒ*and*”h]”hŒand”…””}”(hjå  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hjÝ  ubhŒ¾ 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.”…””}”(hjÝ  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KÅhjÙ  ubhÚ)”}”(hŒÙ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.”h]”hŒÙ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.”…””}”(hjý  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KÊhjÙ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”j©  jª  uh1j  h³hÃh´Kƒhj5  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  h²hh³Nh´Nubj  )”}”(hX  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!

”h]”(hÚ)”}”(hŒü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.”h]”hŒü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.”…””}”(hj!  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KÏhj  ubhÚ)”}”(hX  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!”h]”hX  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!”…””}”(hj/  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KÔhj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hj  h²hh³hÃh´Nubeh}”(h]”h ]”h"]”h$]”h&]”j©  jª  uh1j  h³hÃh´KhhÆh²hubhÅ)”}”(hhh]”(hÊ)”}”(hŒ"EXAMPLE OF AMPLIFIED RCU-USAGE BUG”h]”hŒ"EXAMPLE OF AMPLIFIED RCU-USAGE BUG”…””}”(hjL  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhjI  h²hh³hÃh´KÜubhÚ)”}”(hX  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::”h]”hX  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:”…””}”(hjZ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´KÞhjI  h²hubj  )”}”(hX&  struct foo {
        int a;
        int b;
        int c;
};
struct foo *gp1;
struct foo *gp2;

void updater(void)
{
        struct foo *p;

        p = kmalloc_obj(*p);
        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);
}”h]”hX&  struct foo {
        int a;
        int b;
        int c;
};
struct foo *gp1;
struct foo *gp2;

void updater(void)
{
        struct foo *p;

        p = kmalloc_obj(*p);
        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);
}”…””}”hjh  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´KãhjI  h²hubhÚ)”}”(hXd  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.”h]”hXl  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.”…””}”(hjv  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MhjI  h²hubhÚ)”}”(hŒ4But suppose that the reader needs a consistent view?”h]”hŒ4But suppose that the reader needs a consistent view?”…””}”(hj„  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MhjI  h²hubhÚ)”}”(hŒ>Then one approach is to use locking, for example, as follows::”h]”hŒ=Then one approach is to use locking, for example, as follows:”…””}”(hj’  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MhjI  h²hubj  )”}”(hX  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_obj(*p);
        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);
}”h]”hX  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_obj(*p);
        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);
}”…””}”hj   sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´MhjI  h²hubhÚ)”}”(hŒ*As always, use the right tool for the job!”h]”hŒ*As always, use the right tool for the job!”…””}”(hj®  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MRhjI  h²hubeh}”(h]”Œ"example-of-amplified-rcu-usage-bug”ah ]”h"]”Œ"example of amplified rcu-usage bug”ah$]”h&]”uh1hÄhhÆh²hh³hÃh´KÜubhÅ)”}”(hhh]”(hÊ)”}”(hŒ)EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH”h]”hŒ)EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH”…””}”(hjÇ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhjÄ  h²hh³hÃh´MVubhÚ)”}”(hXŸ  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.”h]”hXŸ  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.”…””}”(hjÕ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MXhjÄ  h²hubhÚ)”}”(hŒuBut without rcu_dereference(), the compiler knows more than you might
expect.  Consider the following code fragment::”h]”hŒtBut without rcu_dereference(), the compiler knows more than you might
expect.  Consider the following code fragment:”…””}”(hjã  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M_hjÄ  h²hubj  )”}”(hXy  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. */
}”h]”hXy  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. */
}”…””}”hjñ  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´MbhjÄ  h²hubhÚ)”}”(hX  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.”h]”hX5  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.”…””}”(hjÿ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M€hjÄ  h²hubhÚ)”}”(hŒfIn short, rcu_dereference() is *not* optional when you are going to
dereference the resulting pointer.”h]”(hŒIn short, rcu_dereference() is ”…””}”(hj  h²hh³Nh´Nubjl  )”}”(hŒ*not*”h]”hŒnot”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jk  hj  ubhŒB optional when you are going to
dereference the resulting pointer.”…””}”(hj  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M‰hjÄ  h²hubeh}”(h]”Œ)example-where-the-compiler-knows-too-much”ah ]”h"]”Œ)example where the compiler knows too much”ah$]”h&]”uh1hÄhhÆh²hh³hÃh´MVubhÅ)”}”(hhh]”(hÊ)”}”(hŒ<WHICH MEMBER OF THE rcu_dereference() FAMILY SHOULD YOU USE?”h]”hŒ<WHICH MEMBER OF THE rcu_dereference() FAMILY SHOULD YOU USE?”…””}”(hj8  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhj5  h²hh³hÃh´MŽubhÚ)”}”(hXQ  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:”h]”hXQ  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:”…””}”(hjF  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Mhj5  h²hubhŒenumerated_list”“”)”}”(hhh]”(j  )”}”(hXì  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.
”h]”hÚ)”}”(hXë  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.”h]”hXë  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.”…””}”(hj]  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M–hjY  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjV  h²hh³hÃh´Nubj  )”}”(hX&  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));

”h]”(hÚ)”}”(hŒ§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::”h]”hŒ¦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:”…””}”(hju  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M hjq  ubj  )”}”(hŒkp1 = rcu_dereference_check(p->rcu_protected_pointer,
                           lockdep_is_held(&my_lock));”h]”hŒkp1 = rcu_dereference_check(p->rcu_protected_pointer,
                           lockdep_is_held(&my_lock));”…””}”hjƒ  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´M¤hjq  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjV  h²hh³hÃh´Nubj  )”}”(hX{  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));
”h]”(hÚ)”}”(hŒ»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::”h]”hŒº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:”…””}”(hj›  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M¨hj—  ubj  )”}”(hŒ¥p1 = rcu_dereference_check(p->rcu_protected_pointer,
                           lockdep_is_held(&my_lock) ||
                           lockdep_is_held(&your_lock));”h]”hŒ¥p1 = rcu_dereference_check(p->rcu_protected_pointer,
                           lockdep_is_held(&my_lock) ||
                           lockdep_is_held(&your_lock));”…””}”hj©  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´M¬hj—  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjV  h²hh³hÃh´Nubj  )”}”(hXr  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.
”h]”(hÚ)”}”(hŒqIf the access is on the update side, so that it is always protected
by my_lock, use rcu_dereference_protected()::”h]”hŒpIf the access is on the update side, so that it is always protected
by my_lock, use rcu_dereference_protected():”…””}”(hjÁ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M°hj½  ubj  )”}”(hŒsp1 = rcu_dereference_protected(p->rcu_protected_pointer,
                               lockdep_is_held(&my_lock));”h]”hŒsp1 = rcu_dereference_protected(p->rcu_protected_pointer,
                               lockdep_is_held(&my_lock));”…””}”hjÏ  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´M³hj½  ubhÚ)”}”(hŒyThis can be extended to handle multiple locks as in #3 above,
and both can be extended to check other conditions as well.”h]”hŒyThis can be extended to handle multiple locks as in #3 above,
and both can be extended to check other conditions as well.”…””}”(hjÝ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M¶hj½  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjV  h²hh³hÃh´Nubj  )”}”(hX  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).

”h]”(hÚ)”}”(hX'  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.”h]”hX'  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.”…””}”(hjõ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´M¹hjñ  ubhÚ)”}”(hŒì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).”h]”hŒì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).”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MÃhjñ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j
  hjV  h²hh³hÃh´Nubeh}”(h]”h ]”h"]”h$]”h&]”Œenumtype”Œarabic”Œprefix”hŒsuffix”Œ.”uh1jT  hj5  h²hh³hÃh´M–ubeh}”(h]”Œ9which-member-of-the-rcu-dereference-family-should-you-use”ah ]”h"]”Œ<which member of the rcu_dereference() family should you use?”ah$]”h&]”uh1hÄhhÆh²hh³hÃh´MŽubhÅ)”}”(hhh]”(hÊ)”}”(hŒ)SPARSE CHECKING OF RCU-PROTECTED POINTERS”h]”hŒ)SPARSE CHECKING OF RCU-PROTECTED POINTERS”…””}”(hj-  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÉhj*  h²hh³hÃh´MÊubhÚ)”}”(hX  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::”h]”hX  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:”…””}”(hj;  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MÌhj*  h²hubj  )”}”(hŒTp = q->rcu_protected_pointer;
do_something_with(p->a);
do_something_else_with(p->b);”h]”hŒTp = q->rcu_protected_pointer;
do_something_with(p->a);
do_something_else_with(p->b);”…””}”hjI  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´MÑhj*  h²hubhÚ)”}”(hŒ~If register pressure is high, the compiler might optimize "p" out
of existence, transforming the code to something like this::”h]”hŒIf register pressure is high, the compiler might optimize â€œpâ€ out
of existence, transforming the code to something like this:”…””}”(hjW  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MÕhj*  h²hubj  )”}”(hŒddo_something_with(q->rcu_protected_pointer->a);
do_something_else_with(q->rcu_protected_pointer->b);”h]”hŒddo_something_with(q->rcu_protected_pointer->a);
do_something_else_with(q->rcu_protected_pointer->b);”…””}”hje  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´MØhj*  h²hubhÚ)”}”(hX  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.”h]”hX  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.”…””}”(hjs  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´MÛhj*  h²hubhÚ)”}”(hŒƒLoad tearing could of course result in dereferencing a mashup of a pair
of pointers, which also might fatally disappoint your code.”h]”hŒƒLoad tearing could of course result in dereferencing a mashup of a pair
of pointers, which also might fatally disappoint your code.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Màhj*  h²hubhÚ)”}”(hŒZThese problems could have been avoided simply by making the code instead
read as follows::”h]”hŒYThese problems could have been avoided simply by making the code instead
read as follows:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Mãhj*  h²hubj  )”}”(hŒep = rcu_dereference(q->rcu_protected_pointer);
do_something_with(p->a);
do_something_else_with(p->b);”h]”hŒep = rcu_dereference(q->rcu_protected_pointer);
do_something_with(p->a);
do_something_else_with(p->b);”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´Mæhj*  h²hubhÚ)”}”(hX  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::”h]”hX  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:”…””}”(hj«  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Mêhj*  h²hubj  )”}”(hŒ(struct foo __rcu *rcu_protected_pointer;”h]”hŒ(struct foo __rcu *rcu_protected_pointer;”…””}”hj¹  sbah}”(h]”h ]”h"]”h$]”h&]”j  j   uh1j  h³hÃh´Móhj*  h²hubhÚ)”}”(hŒcUse of "__rcu" is opt-in.  If you choose not to use it, then you should
ignore the sparse warnings.”h]”hŒgUse of â€œ__rcuâ€ is opt-in.  If you choose not to use it, then you should
ignore the sparse warnings.”…””}”(hjÇ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙh³hÃh´Mõhj*  h²hubeh}”(h]”Œ)sparse-checking-of-rcu-protected-pointers”ah ]”h"]”Œ)sparse checking of rcu-protected pointers”ah$]”h&]”uh1hÄhhÆh²hh³hÃh´MÊubeh}”(h]”(Œ=proper-care-and-feeding-of-return-values-from-rcu-dereference”hÂeh ]”h"]”(Œ?proper care and feeding of return values from rcu_dereference()”Œrcu_dereference_doc”eh$]”h&]”uh1hÄhhh²hh³hÃh´KŒexpect_referenced_by_name”}”jã  h·sŒexpect_referenced_by_id”}”hÂh·subeh}”(h]”h ]”h"]”h$]”h&]”Œsource”hÃuh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(hÉNŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”•B      Œutf-8”Œoutput_encoding_error_handler”j  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”hÃŒ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”hÂ]”h·asŒnameids”}”(jã  hÂjâ  jß  jÁ  j¾  j2  j/  j'  j$  jÚ  j×  uŒ	nametypes”}”(jã  ˆjâ  ‰jÁ  ‰j2  ‰j'  ‰jÚ  ‰uh}”(hÂhÆjß  hÆj¾  jI  j/  jÄ  j$  j5  j×  j*  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”hŒsystem_message”“”)”}”(hhh]”hÚ)”}”(hhh]”hŒ9Hyperlink target "rcu-dereference-doc" is not referenced.”…””}”hjw  sbah}”(h]”h ]”h"]”h$]”h&]”uh1hÙhjt  ubah}”(h]”h ]”h"]”h$]”h&]”Œlevel”KŒtype”ŒINFO”Œsource”hÃŒline”Kuh1jr  ubaŒtransformer”NŒinclude_log”]”Œ
decoration”Nh²hub.