[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LSU.2.20.1708101254540.7971@pobox.suse.cz>
Date: Thu, 10 Aug 2017 13:12:25 +0200 (CEST)
From: Miroslav Benes <mbenes@...e.cz>
To: Jason Baron <jbaron@...mai.com>
cc: linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
jpoimboe@...hat.com, jeyu@...nel.org, jikos@...nel.org,
pmladek@...e.com
Subject: Re: [PATCH 0/3] livepatch: introduce atomic replace
> Ok - associating the "atomic replace" with the patch itself makes sense to me.
> It would also basically work, I think with the patch I proposed except for the
> case where the the "atomic replace" was on top of several non-"atomic replace"
> patches. The reason is that the "atomic replace" I posted looks back 1 patch
> to see what it needs to replace (assuming all patches are in atomic replace
> mode). So instead of just looking back 1 patch, it could 'look back' and make
> sure it was replacing all previously loaded patches.
Yes, this should not be a problem to implement with the current code.
But I must say I am not entirely happy with the code as it is. The big
advantage is that there are almost no changes to the consistency model.
Almost everything is created and allocated during the initialization and
the patch then looks ordinary. The current code can handle it smoothly.
"Dynamic" superstructure is what I am not happy with. It is too
complicated in my opinion. On the other hand I don't see a simple way out
now.
1. We can try to make your code "nicer".
2. The main problem is that all user structures (klp_func, klp_object,
klp_patch) are statically allocated in a kernel module. You need to add
dynamically allocated structures, which is not easy. We can either change
everything to dynamic allocation, or make everything static. As far as the
former is concerned, we've been down that road IIRC. It didn't end up
well. Is the latter even possible?
3. We could bypass everything and register special no-op fops to each
reverted function. Those could be held and handled separately. It could be
simpler, but it might be problematic to deal with the consistency model
interaction.
Thoughts?
Regards,
Miroslav
Powered by blists - more mailing lists