On Mon, 27 Jun 2016, Pavel Machek wrote: > > > I thought that in such case, person creating the live patch should > > > notice and adjust patch appropriately, at assembly level if > > > neccessary..? > > > > Yes, that still holds; a lot of things could be automated though, and > > creating the automation tools is one of the big TODO items. > > So the patch is not a bugfix, it is just something that slows down > kernel to make stuff easier for the person doing the live patching...? Well, up to the last week noone realized the implications IPA-RA has for live patches. Now that we know about this, we have to deal with it somehow; as currently gcc doesn't provide easy way for us to obtain the information (non-existing -fdump-ipa-ra), disabling the optimization on CONFIG_LIVEPATCH-enabled kernels is a sensible workaround before we're able to get the information from gcc. > What you actually want is "whenever source of function A influenced code > in function B, I want to be notified", right? > > If gcc can eliminate an if() brach in function B, because it can tell > reading function A it can not happen, you need to know. Maybe that's > limited to ABI today, but... Yeah; dead code elimination is also a thing to watch for. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
