On Wed, Jul 22, 2015 at 10:21:54PM +0200, Jiri Kosina wrote: > On Wed, 22 Jul 2015, Josh Poimboeuf wrote: > > > > That will still maintain the property of being unique and in > > > !kptr_restrict cases will provide address as a benefit. > > > > Hm, but what if kptr_restrict gets changed after we create the kobject? > > If kptr_restrict == 1, we could just make the directory visible only to > the holders of the corresponding capabilities. > > For kptr_restrict == 2, there is really no good solution indeed. I suppose we could do "func,n", where n refers to the nth occurrence of the symbol name in the kallsyms list for the given object. For example: $ grep " t_next" /proc/kallsyms ffffffff811597d0 t t_next -> "t_next,0" ffffffff81163bb0 t t_next -> "t_next,1" ... In my kernel there are 6 functions named t_next in vmlinux. "t_next,0" would refer to the function at 0xffffffff811597d0. "t_next,1" would refer to the one at 0xffffffff81163bb0. While we're at it, we might also encode the replacement function name: "t_next,0,t_next__patched". I'm not sure if it's wise to rely on kallsyms always being in a deterministic order though. Thoughts? -- 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
