Lines Matching refs:a

5 Shadow variables are a simple way for livepatch modules to associate
11 The implementation introduces a global, in-kernel hashtable that
12 associates pointers to parent objects and a numeric identifier of the
13 shadow data.  The numeric identifier is a simple enumeration that may be
27 stored and retrieved through a <obj, id> pair.
41 They also allow to call a custom constructor function when a non-zero
46 to do actions that can be done only once when a new variable is allocated.
48 * klp_shadow_get() - retrieve a shadow variable data pointer
51 * klp_shadow_alloc() - allocate and add a new shadow variable
60     - allocate a new shadow variable
61     - initialize the variable using a custom constructor and data when provided
64 * klp_shadow_get_or_alloc() - get existing or alloc a new shadow variable
73     - allocate a new shadow variable
74     - initialize the variable using a custom constructor and data when provided
77 * klp_shadow_free() - detach and free a <obj, id> shadow variable
78   - find and remove a <obj, id> reference from global hashtable
101 ("mac80211: fix AP powersave TX vs.  wakeup race"), which added a
103 example can be considered a stand-alone livepatch implementation of this
119 For commit 1d147bfa6429, when a parent sta_info structure is allocated,
120 allocate a shadow copy of the ps_lock pointer, then initialize it::
132 	/* Attach a corresponding shadow variable, then initialize it */
140 When requiring a ps_lock, query the shadow variable API to retrieve one
141 for a specific struct sta_info:::
167 variables alongside their parent objects.  Or a livepatch fix may
168 require shadow variables for only a subset of parent object instances.
172 For commit 1d147bfa6429, a good spot to allocate a shadow spinlock is
197 This usage will create a shadow variable, only if needed, otherwise it
208 Shadow variables can also be used as a flag indicating that a data
226   a datatype update technique called "shadow data structures".