This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Kernel livepatching support in GCC
- From: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, Richard Guenther <richard dot guenther at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, Li Bin <huawei dot libin at huawei dot com>, Andi Kleen <ak at linux dot intel dot com>, Takahiro Akashi <takahiro dot akashi at linaro dot org>
- Date: Tue, 09 Jun 2015 16:10:31 +0200
- Subject: Re: [RFC] Kernel livepatching support in GCC
- Authentication-results: sourceware.org; auth=none
- References: <844CBBAF-DA0E-4164-9E35-34075A26F665 at linaro dot org> <CEDC3659-14B8-42A4-9ED8-485EC62B615C at gmail dot com> <535E656D-9CA2-4506-8918-CD73C0F63F84 at linaro dot org> <55673651 dot 8070802 at linux dot vnet dot ibm dot com> <20150604071531 dot GA17023 at domone>
On 06/04/2015 09:15 AM, OndÅej BÃlka wrote:
> On Thu, May 28, 2015 at 05:37:53PM +0200, Andreas Krebbel wrote:
>> On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote:
>>>> On May 28, 2015, at 11:59 AM, Richard Biener <email@example.com> wrote:
>>>> Maybe follow s390 -mhotpatch instead?
>>> Regarding implementation of the option, it will follow what s390 is doing with function attributes to mark which functions to apply nop-treatment to (using attributes will avoid problems with [coming] LTO builds of the kernel). The new option will set value of the attribute on all functions in current compilation unit, and then nops will be generated from the attribute specification.
>>> On the other hand, s390 does not generate a section of descriptor entries of NOP pads, which seems like a useful (or necessary) option. A more-or-less generic implementation should, therefore, combine s390's attributes approach to annotating functions and x86's approach to providing information in an ELF section about NOP entries. Or can we record value of a function attribute in ELF in a generic way?
>> I agree that would be useful. The only reason we didn't implement that was that our kernel guys were
>> confident enough to be able to detect patchable functions without it. We discussed two solutions to
>> 1. Add special relocations pointing to the patchable areas.
>> 2. Add a special section listing all patchable areas. I think systemtap is doing something similiar
>> for their probes.
> As I am bit concerned with performance why require nops there? Add a
> byte count number >= requested thats boundary of next instruction. When
> lifepatching for return you need to copy this followed by jump back to next
> instruction. Then gcc could fill that with instructions that don't
> depend on address, fill with nops as trivial first implementation.
> Would that be possible?
So instead of placing NOPs to be overwritten you intend to simply overwrite the existing code after
making a backup of it? While that sounds appealing I think you could run into trouble when trying
to atomically patch the code. On S/390 it could happen that you overwrite 3 2 byte instructions
with a 6 byte instruction. The effect of the first two might be visible when doing the update so you
would have to keep all CPUs outside this area when patching. With the -mhotpatch option it is
guaranteed that a 6 byte NOP is used. With the proper alignment we can do an atomic update then.
For your approach we have to arrange that bigger instructions get scheduled first and if this isn't
possible we would have to add proper NOPs instead. That might be an improvement which could be added
to that feature.
Btw. we have compared several benchmarks with kernels either using or not using -mhotpatch and there
was no noticable penalty. However, I agree that it would be nice to get rid of the NOPs althogether.