On Tue, Sep 03, 2019 at 03:02:34PM +0200, Miroslav Benes wrote:

On Mon, 2 Sep 2019, Joe Lawrence wrote:

quoted

On 9/2/19 12:13 PM, Miroslav Benes wrote:

quoted

quoted

I can easily foresee more problems like those in the future.  Going
forward we have to always keep track of which special sections are
needed for which architectures.  Those special sections can change over
time, or can simply be overlooked for a given architecture.  It's
fragile.

Indeed. It bothers me a lot. Even x86 "port" is not feature complete in
this regard (jump labels, alternatives,...) and who knows what lurks in
the corners of the other architectures we support.

So it is in itself reason enough to do something about late module
patching.

Hi Miroslav,

I was tinkering with the "blue-sky" ideas that I mentioned to Josh the other
day.

quoted

I dunno if you had a chance to look at what removing that code looks
like, but I can continue to flesh out that idea if it looks interesting:

Unfortunately no and I don't think I'll come up with something useful 
before LPC, so anything is really welcome.

quoted

  https://github.com/joe-lawrence/linux/tree/blue-sky

I like this a lot.

quoted

A full demo would require packaging up replacement .ko's with a livepatch, as
well as "blacklisting" those deprecated .kos, etc.  But that's all I had time
to cook up last week before our holiday weekend here.

Frankly, I'm not sure about this approach. I'm kind of torn. The current 
solution is far from ideal, but I'm not excited about the other options 
either. It seems like the choice is basically between "general but 
technically complicated fragile solution with nontrivial maintenance 
burden", or "something safer and maybe cleaner, but limiting for 
users/distros". Of course it depends on whether the limitation is even 
real and how big it is. Unfortunately we cannot quantify it much and that 
is probably why our opinions (in the email thread) differ.

How would this option be "limiting for users/distros"?  If the packaging
part of the solution is done correctly then I don't see how it would be
limiting.

-- 
Josh