Patent Application
20100269106
When software developers correct a problem in the source code of a computer program (such as an operating system kernel), they typically create and distribute a patch, which consists of a set of changes to the source code. Software vendors or system administrators apply the patch to their copy of the source code, build a new binary copy of the computer program, and then distribute that new binary program to servers and end-user machines. The computer program must then be restarted in order to benefit from the update. Restarting programs in order to update them can cause undesirable disruption.
A “hot update” changes a running program without restarting it. A hot update system installs updates in a running program as follows. First, the hot update is loaded into the running program and initialized. The hot update then locates the code entry points in the running program's memory that are to be modified. Then, at a safe time, the hot update will insert trampolines (jump instructions) at those locations. These trampolines will direct execution away from the obsolete code to new code, located elsewhere, that has been loaded into program memory as part of the hot update.
A key problem in this process is finding a safe time to modify the code of the running program by inserting the trampolines. It is in general unsafe to insert trampolines into a function that is in the process of being executed by any program thread. There are two common reasons why inserting trampolines into a function that is being executed by a program thread is unsafe. First, inserting the trampolines involves overwriting some of the code of the running function at each of the entry points, which could result in incorrect behavior if the thread executing the running function later attempts to execute any of the overwritten code. Second, many patches must be applied to multiple functions atomically (in an all-or-nothing fashion) in order to ensure safety, and the transition will not be atomic if a thread was in the process of executing a function being patched when the trampolines were inserted. For example, if a patch changes the locking semantics of a set of functions, then a deadlock could occur if the trampolines were inserted while one of the functions was being executed.
Existing hot update systems (e.g., OPUS) have addressed the problem of finding a safe time to apply a hot update by requiring certain program execution metadata, specifically a frame pointer chain, to be available for each program thread. This metadata is used to perform a specific check for every frame associated with every thread stack. Specifically, the check is whether the frame instruction pointer falls within any of the patched functions.
Because many deployed systems do not have this metadata available, existing techniques are commonly ineffective for performing the hot update safety check, preventing these systems from being updated using hot updates.
The present invention is an improved method for safely performing hot updates to a running computer program. Specifically, the present invention is a technique for finding a safe time to modify the executable code of a running computer program. Unlike existing techniques, the present invention works even in the absence of detailed program execution metadata, such as a frame pointer chain.
The present invention will become more fully understood from the detailed description given below and the accompanying drawing, which are given by way of illustration only and thus are not limitative of the present invention, wherein:
As used herein, the term “computer program” or “program” refers to any computer program, including an operating system kernel.
The present invention is a novel method for finding a safe time to apply a hot update that is effective even in the case wherein that frame pointer metadata is not available.
First, the present invention determines a list of functions that will be modified as part of the changes to the running computer program. This list can be determined using any technique, such as an analysis of a source code patch.
Using this list of functions that will be modified, the present invention then determines the start memory address and the end memory address of each function that will be modified in the running computer program. These memory addresses can be determined using any technique, such as looking up the function's address in a program symbol table.
Using those start and end memory addresses for each function that will be modified, the present invention determines whether the execution stack of any thread in the running computer program contains any numeric value, located anywhere in the stack, that is greater than or equal to the start address of the function and less than the end address of the function.
Using this information about whether any execution stack contains such a value, the present invention determines whether the running computer program is currently in a state of execution such that it can be modified safely. Specifically, if any execution stack contains such a value, the program is not in a state of execution such that it can be modified safely. Because the execution state of program threads changes over time, the update process can be repeated at one or more later times in case the condition is not currently satisfied.
The present invention will always detect a conflict if a conflict does exist, regardless of whether the frame pointer metadata is available.
Thus, the improved method of the present invention can be summarized as follows:
In a method of modifying code of a running computer program so as to modify the running computer program without having to restart the running computer program for changes to the running computer program to take effect, the improvement of including the following steps in said method:
step (a)—determining a list of functions that will be modified as part of said changes to the running computer program; and
step (b)—using the results of step (a), determining, for a function that will be modified as part of said changes to the running computer program, the start memory address of said function in said running computer program and the end memory address of said function in said running computer program; and
step (c)—using the results of step (b), determining, for a function that will be modified as part of said changes to the running computer program, whether an execution stack of any thread in the running computer program contains, located in any position on said execution stack, any numeric value that:
step (d)—using the results of step (c), specifically, based on whether both condition (c)(1) and condition (c)(2) are true, determining whether said running computer program is currently in a state of execution such that it can be modified safely. If no execution stack contains such a numeric value, the program is in a state of execution such that it can be modified safely.
The invention being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the spirit and scope of the invention. Rather, the scope of the invention shall be defined as set forth in the following claims and their legal equivalents. All such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.
