On Fri, Nov 07, 2014 at 01:48:45PM +0100, Vojtech Pavlik wrote: > On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote: > > On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote: > > > On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote: > > > > > > > On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote: > > > > > I don't think this specific example was generated. > > > > > > > > > > I also don't think including the whole kpatch automation into the kernel > > > > > tree is a viable development model for it. (Same would apply for kGraft > > > > > automation.) > > > > > > > > Why? We (IMHO incorrectly) used the argument of tight coupling to put > > > > perf into the kernel tree. Generating kernel live patches is way more > > > > integrated that it absolutely has to go into the tree to be able to do > > > > proper development on it in an integrated fashion. > > > > > > One reason is that there are currently at least two generators using > > > very different methods of generation (in addition to the option of doing > > > the patch module by hand), and neither of them are currently in a state > > > where they would be ready for inclusion into the kernel (although the > > > kpatch one is clearly closer to that). > > > > What generator does kGraft have? Is that the one that generates the > > source patch, or is there one that generates a binary patch module? > > The generator for kGraft: > > * extracts a list of changed functions from a patch (rather naïvely so far) > * uses DWARF debuginfo of the old kernel to handle things like inlining > and create a complete list of functions that need to be replaced > * compiles the kernel with -fdata-sections -ffunction-sections > * uses a modified objcopy to extract functions from the kernel > into a single .o file > * creates a stub .c file that references those functions > * compiles the .c and links with the .o to build a .ko > > The main difference is in that the kGraft generator doesn't try to > compare the old and new binary objects, but rather works with function > lists and the DWARF info of the old code and extracts new functions from > the new binary. Thanks, interesting. Sounds like we're mostly on the same page here. > > However, as I said before, we have found enough trouble around eg. > IPA-SRA and other optimizations that make any automated approach fragile > and in our view more effort than benefit. Hence, we're intend to use the > manual way of creating live patches until proven that we were wrong in > this assessment. :) Yeah. We've already put in a lot of effort to support the gcc optimizations like IPA-SRA, partial inlining, static variable renaming, etc. And also added support for many kernel special sections. For now, at least, it works very well, and we find that generation is _much_ easier and less error-prone than the manual approach. So in our experience, the benefits far outweigh the effort. But I do agree that it's fragile, and at the mercy of any future gcc optimization features. Which is why I like our current approach of supporting the manual approach as well. The manual approach isn't optimal, but it is a nice backup solution for us in case something causes the generator to break. -- Josh -- 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
