Re: [RFC PATCH] livepatch: allow removal of a disabled patch

From: Jiri Kosina
Date: Thu May 05 2016 - 17:08:59 EST

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

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.


Jiri Kosina