On Thu, 2014-05-08 at 18:46 -0700, David Lang wrote: > On Wed, 7 May 2014, Ingo Molnar wrote:
> It's possible to have two versions of code that each work independently, but > that you can't switch between easily on the fly. > > If the new code assumes a lock is held that the old code didn't take, then > when > you switch, you are eventually going to hit a case where the new code trys to > release a lock it doesn't hold. But we are replacing full functions here. Never half way through. Thus, there should never be "old code didn't take", because we replace the entire function. If the new code expects a lock to be held where the old code did not, there's nothing changing anything that leads up to this new code. The lock still won't be taken. A patch that expects that wont work on a reboot either. > > detecting all possible cases progromatically seems close to impossible. > > but this means that there are two categories of patches > > 1. patches that are safe to put in a kernel that you are going to boot from > > 2. patches that are able to be applied on the fly > > and the tool isn't going to be able to tell you which category the patch is > in. > It can identify some of the items that make it unlikely or impossible for the > patch to belong to #2, but don't rely on the tool catching all of them I agree that live patching is going to be a bit trickier than patches that are applied for reboot. And I also agree that no tool could determine if the patch can be applied live even if it could be applied safely for reboot. To do so would probably be on the difficulty scale of the halting problem. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
