On Thu, 5 May 2016, Josh Poimboeuf wrote: > I would disagree with the statement that the dynamic kobject doesn't > scale. We would just need a helper function to get from a kobject to > its klp_patch. > > In fact, to me it seems like the right way to do it. It doesn't make > sense for the code which creates the kobject to be different from the > code which initializes it. It's slightly out of context, but > kobject.txt does say: > > "Code which creates a kobject must, of course, initialize that object." > > I view the completion as a hack to compensate for the fact that we're > abusing the kobject interface. And so it makes sense to me that > CONFIG_DEBUG_KOBJECT_RELEASE would cause problems, because we're using > kobjects in the wrong way. > > So in my view, the two options are: > > 1. Convert the kobject to dynamic as I described. > > 2. Change the klp_register() interface so that klp_patch gets allocated > in livepatch code. > > I'd be curious to hear what others think. My understanding is that the concern here is that walking through the complete linked list every time sysfs node is accessed, just to figure out whether we're able to find a klp_patch entry that points back to the particular kobject that's being passed to the sysfs callback, isn't really super-efficient. I personally wouldn't worry *that* much about that particular aspect (sysfs operations are hardly considered time critical anyway), but I'd have to think a bit more whether this is really safe wrt. deadlocks between kernfs locks and klp_mutex; but so far it seems to me that klp_mutex always nests below kernfs, so it should be OK. Unfortunately, this still feels like a non-negligible (mis|ab)use of kobjects that could bite us later wrt. maintainability and general clarity of the code, and therefore tying klp_patch lifetime to (de)allocations from within livepatch code itself seems like much better idea to me. Thanks, -- 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
