[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.2005050019060.19713@cbobk.fhfr.pm>
Date: Tue, 5 May 2020 00:20:34 +0200 (CEST)
From: Jiri Kosina <jikos@...nel.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
cc: live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Jessica Yu <jeyu@...nel.org>,
Joe Lawrence <joe.lawrence@...hat.com>,
Miroslav Benes <mbenes@...e.cz>
Subject: Re: [PATCH v4 00/11] livepatch,module: Remove .klp.arch and
module_disable_ro()
On Wed, 29 Apr 2020, Josh Poimboeuf wrote:
> v4:
> - Fixed rebase bisection regression [Miroslav]
> - Made module_enable_ro() static [Jessica]
> - Added Acked-by's
>
> v3:
> - klp: split klp_write_relocations() into object/section specific
> functions [joe]
> - s390: fix plt/got writes [joe]
> - s390: remove text_mutex usage [mbenes]
> - x86: do text_poke_sync() before releasing text_mutex [peterz]
> - split x86 text_mutex changes into separate patch [mbenes]
>
> v2:
> - add vmlinux.ko check [peterz]
> - remove 'klp_object' forward declaration [mbenes]
> - use text_mutex [jeyu]
> - fix documentation TOC [jeyu]
> - fix s390 issues [mbenes]
> - upstream kpatch-build now supports this
> (though it's only enabled for Linux >= 5.8)
>
> These patches add simplifications and improvements for some issues Peter
> found six months ago, as part of his non-writable text code (W^X)
> cleanups.
>
> Highlights:
>
> - Remove the livepatch arch-specific .klp.arch sections, which were used
> to do paravirt patching and alternatives patching for livepatch
> replacement code.
>
> - Add support for jump labels in patched code (only for static keys
> which live in vmlinux).
>
> - Remove the last module_disable_ro() usage.
>
> For more background, see this thread:
>
> https://lkml.kernel.org/r/20191021135312.jbbxsuipxldocdjk@treble
>
> This has been tested with kpatch-build integration tests and klp-convert
> selftests.
So I think this should best go through livepatching.git for 5.8. Unless
anyone has a better idea or objects heavily, I'll queue it tomorrow.
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists