[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPhsuW5GuADzdnsBi9Nx0Rrv2FRnO3c5SwdYA01ZShOCf6RY+A@mail.gmail.com>
Date: Thu, 12 Sep 2024 09:05:44 -0700
From: Song Liu <song@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Petr Mladek <pmladek@...e.com>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org, x86@...nel.org, Miroslav Benes <mbenes@...e.cz>,
Joe Lawrence <joe.lawrence@...hat.com>, Jiri Kosina <jikos@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Marcos Paulo de Souza <mpdesouza@...e.com>,
A K M Fazla Mehrab <a.mehrab@...edance.com>
Subject: Re: [RFC 00/31] objtool, livepatch: Livepatch module generation
Hi Josh,
On Wed, Sep 11, 2024 at 9:20 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
[...]
> > Do not get me wrong. I do not expect that the upstream variant would
> > be feature complete from the beginning. I just want to get a picture
> > how far it is. The code will be maintained only when it would have
> > users. And it would have users only when it would be comparable or
> > better then kPatch.
>
> I agree it needs to be fully functional before merge, but only for x86.
>
> Red Hat (and Meta?) will start using it as soon as x86 support is ready,
> because IBT/LTO support is needed, which kpatch-build can't handle.
While we (Meta) do have a workaround in kpatch to build livepatch for
kernels built with LTO, we will try to switch to this approach once
the x86 support is ready.
There are also other companies that would like to use LTO+livepatch
combination.
Thanks,
Song
Powered by blists - more mailing lists