From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85554 invoked by alias); 24 Feb 2020 17:11:59 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 85546 invoked by uid 89); 24 Feb 2020 17:11:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Feb 2020 17:11:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582564316; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=JklncL6j3tqeI94UwYZMF1NqLSA6W3z93HwP8kTfCyY=; b=KPlm549AWo6zr44pjpnccMMMZ5b2NY5+zTanJyRnQUhVGoXPopxH1JjfsQbnkO2O3/70JX UsJUb8pjDh3+GXd+z250Vn7xy4eYAljWS/uF8tzVlYh0W4HxCNAwHCF96XiNVCeIIXkuLc DT5YUdg8q5YH1/gwCf4J2uHErtqeU5U= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-191-YtzCjtK-Mm2p-qfgfblsDA-1; Mon, 24 Feb 2020 12:11:53 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7C560108595B; Mon, 24 Feb 2020 17:11:52 +0000 (UTC) Received: from [10.36.117.148] (ovpn-117-148.ams2.redhat.com [10.36.117.148]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AEB7F1001B07; Mon, 24 Feb 2020 17:11:51 +0000 (UTC) To: Fangrui Song Cc: Alan Modra , binutils@sourceware.org References: <877e0pmpew.fsf@redhat.com> <20200218002019.GD5570@bubble.grove.modra.org> <20200224063852.2seelvdhlvzhxw53@google.com> From: Nick Clifton Subject: Re: RFC: Supporting multiple relocs per section Message-ID: <73733678-72db-2d63-c290-3355d8bf1fe0@redhat.com> Date: Mon, 24 Feb 2020 17:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200224063852.2seelvdhlvzhxw53@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00531.txt.bz2 Hi Fangrui, > Where can we find more information about the kernel side implementation, > if it is open? You might like to start with these articles: https://access.redhat.com/articles/2475321 https://www.redhat.com/en/blog/live-kernel-patching-update There is also a mailing list where you can post questions: live-patching@vger.kernel.org FYI Joe Lawrence - the kernel engineer who has been looking=20 into this - did try using the LLVM toolset but he found that it did not like their use of reserved st_shndx symbol values and the processor specific values in the link field in their=20 relocation sections... Cheers Nick