dynup/kpatch — pull request #398 by flaming-toast (2014-09-04 07:23:34+00:00)
Title: re-enable forced patch modules 

Attempts to address #343, after taking the comments there into consideration.

Quick rundown:
- in kpatch-build, a `.kpatch.checksum` section is added to the final output.o object using `objcopy`.
- in kpatch-patch-hook, the contents of `.kpatch.checksum` are exported to sysfs. `sysfs_create_group` (previously `sysfs_create_file`) moved to the end of `patch_init` to avoid the race condition where `kpatch_register` is called before `kpmod.objects` is fully initialized.
- in the kpatch core module, move the `kpmod->enabled` check in `kpatch_register` to after obtaining the mutex and `try_module_get`. This was done so that If there are concurrent calls to `kpatch_register`, only one would succeed, and the others would see that `kpmod->enabled` is already set true. Same for `kpatch_unregister`.
- in the kpatch script, `load_module` now checks if the given module is already loaded (or if another module with the same name is). If so, verify that the checksums read from the .ko file and the corresponding module in sysfs match.

Other comments:
- The gotos had to be changed up a bit after switching the initialization order in `patch_init`. Help verify that it's still sane :-) Also, not sure if I be calling sysfs_remove_group if sysfs_create_group fails. Doesn't make sense since if it fails the group was never created...Am I missing any other error conditions?
- Note that this won't work with old forced modules since they won't have a checksum section.
- Tested with a forced version of the meminfo patch and loading/unloading/re-enabling works. I might be missing some corner cases, let me know if you catch any.

This is the initial version of this patch so I suspect there may be things I am missing, or perhaps some parts can be done better. :-) As always, feedback is welcome.