Lines Matching refs:patch

59 a live patch is called with the help of a custom ftrace handler. But there are
77 But there are more complex fixes. For example, a patch might change
78 ordering of locking in multiple functions at the same time. Or a patch
97 switch over.  When a patch is enabled, livepatch enters into a
100 sequence occurs when a patch is disabled, except the tasks converge from
108 safe to patch tasks:
112    the task is patched.  In most cases this will patch most or all of
141 Unless we can come up with another way to patch kthreads, architectures
145 The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
146 is in transition.  Only a single patch (the topmost patch on the stack)
147 can be in transition at a given time.  A patch can remain in transition
148 indefinitely, if any of the tasks are stuck in the initial patch state.
151 opposite value to the /sys/kernel/livepatch/<patch>/enabled file while
153 converge back to the original patch state.
157 If a patch is in transition, this file shows 0 to indicate the task is
158 unpatched and 1 to indicate it's patched.  Otherwise, if no patch is in
162 /sys/kernel/livepatch/<patch>/signal attribute provides a better alternative.
169 /sys/kernel/livepatch/<patch>/force attribute. Writing 1 there clears
174 tasks) and request a clearance from a patch distributor to force the transition.
176 patch, which functions are (un)patched, and which functions the blocking tasks
177 are sleeping in (/proc/<pid>/stack may help here). Removal (rmmod) of patch
180 reference count if a patch module is disabled and enabled in a loop.
200    location to switch the kthread's patch state would be at a designated
217    b) patching kthreads and idle tasks at their designated patch points.
220    user tasks and waking kthreads to patch them.  But it could still be
249 The patch contains only functions that are really modified. But they
259 The patch is described by several structures that split the information
285     the patch itself and the relevant functions might be patched
293     synchronously. The whole patch is applied only when all patched
297     For more details on how the patch is applied on a per-task basis,
306 has to register the patch (struct klp_patch) and enable it. See the
315 transitioned to a new patch state (patched/unpatched) without being
323 live patch: registration, enabling, disabling and unregistration.  There are
326 First, the patch is applied only when all patched symbols for already
331 the hybrid consistency model being used. The patch revert might block
333 revert the patch using a separate operation that might be called
341 Each patch first has to be registered using klp_register_patch(). This makes
342 the patch known to the livepatch framework. Also it does some preliminary
345 In particular, the patch is added into the list of known patches. The
349 /sys/kernel/livepatch/<name>. The patch is rejected when any operation
360 When a patch is enabled, livepatch enters into a transition state where
385 either the code from the previously enabled patch or even the original
388 When a patch is disabled, livepatch enters into a transition state where
395 patch are removed from the corresponding struct klp_ops. The ftrace handler
407 This can be done only when the patch is disabled and the code is no longer
410 At this stage, all the relevant sys-fs entries are removed and the patch
421 /sys/kernel/livepatch/<patch>/signal and /sys/kernel/livepatch/<patch>/force
460     the return address. The first user wins. Either the probe or the patch