Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1125465ybe; Thu, 5 Sep 2019 10:40:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqyj7NVs5MJyKstKYDnUiXjbcSFn6dKrGY2gtDhK9ow87urEtGzIskrgbMXlHuTvt0JN5yFZ X-Received: by 2002:a63:6ec1:: with SMTP id j184mr4263783pgc.232.1567705200709; Thu, 05 Sep 2019 10:40:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567705200; cv=none; d=google.com; s=arc-20160816; b=eoSoeuD1cwncO2/iZBs9fszIP5sqTLDA7rqPvYnQqIAIg7gWAyWI/Ia77sGYmxrKa9 ctGA/9kiP3qzMGyQxUzFL3RyfsgykTuTfe/1NAGq84yHXINZwxhQynBQaxYy/S7efYvy 6bqyrU/Denoqxvrq5HTpoeGbDZ/dOfm67qxy2vOOya6KJbX0H7gD03ZlwKn3v19rPuz/ v3Ii8tiKg70iLt5wBMfNx+6L3bl9JqVG+mubyagOxVX/vdVLiAH2cJTw/XUfYJCebt+J xqucEJL1GLiYMEc9OFK1mIltnGQoToAS104+A9asCdGhBBSy2SmgbgUpdEOm7vEoKJcK Zp2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=bUPGcwlcylOSkoriblLe+oT73rDWNxQMK5ldqNRR0gA=; b=tin52fMlKDZM/cZdZaG3sBGyYuSSkEt1dTOWp+469csdNgYfzyVBfzh+da7FzJC6rp Bx0QBWdw7wivTaJhau9qCjDqP63zUvmbJJyjJjsBLQ1dkU/wX+1ty6ljK/0/lz3sgLuF rDpqFOgJO3rPtAFRTsvHu8nBmV32i2ZxYKIKRRGZ4u2MKQvOwlK090wR34akHyEHjgZU 1s+RD2SBKg68ZNCmYlbbzyPADOxnd/0Whmjy3fBYP1YLqqF3iMDmU2qdaLWmfcMxxu6P SiM1G8HKJi14ZzgUReDJr9uBlvW7G6Y3DimGx4vs+lFpM6YPZ6xl4Chr9yXgzxQDuQHB QXkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o132si2805160pfg.249.2019.09.05.10.39.44; Thu, 05 Sep 2019 10:40:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732791AbfIENxA (ORCPT + 99 others); Thu, 5 Sep 2019 09:53:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:54198 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727735AbfIENxA (ORCPT ); Thu, 5 Sep 2019 09:53:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 739D1AF84; Thu, 5 Sep 2019 13:52:59 +0000 (UTC) Date: Thu, 5 Sep 2019 15:52:59 +0200 From: Petr Mladek To: Josh Poimboeuf Cc: jikos@kernel.org, Joe Lawrence , Miroslav Benes , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal Message-ID: <20190905135259.7obdymb7c2wdgafw@pathway.suse.cz> References: <20190823081306.kbkm7b4deqrare2v@pathway.suse.cz> <20190826145449.wyo7avwpqyriem46@treble> <5c649320-a9bf-ae7f-5102-483bc34d219f@redhat.com> <20190904084932.gndrtewubqiaxmzy@pathway.suse.cz> <20190905025055.36loaatxtkhdo4q5@treble> <20190905110955.wl4lwjbnpqybhkcn@pathway.suse.cz> <20190905130832.dznviqrrg6lfrxvx@treble> <20190905131502.mgiaplb3grlxsahp@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190905131502.mgiaplb3grlxsahp@treble> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2019-09-05 08:15:02, Josh Poimboeuf wrote: > On Thu, Sep 05, 2019 at 08:08:32AM -0500, Josh Poimboeuf wrote: > > On Thu, Sep 05, 2019 at 01:09:55PM +0200, Petr Mladek wrote: > > > > I don't have a number, but it's very common to patch a function which > > > > uses jump labels or alternatives. > > > > > > Really? My impression is that both alternatives and jump_labels > > > are used in hot paths. I would expect them mostly in core code > > > that is always loaded. > > > > > > Alternatives are often used in assembly that we are not able > > > to livepatch anyway. > > > > > > Or are they spread widely via some macros or inlined functions? > > > > Jump labels are used everywhere. Looking at vmlinux.o in my kernel: > > > > Relocation section [19621] '.rela__jump_table' for section [19620] '__jump_table' at offset 0x197873c8 contains 11913 entries: > > > > Each jump label entry has 3 entries, so 11913/3 = 3971 jump labels. > > > > $ readelf -s vmlinux.o |grep FUNC |wc -l > > 46902 > > > > 3971/46902 = ~8.5% > > > > ~8.5% of functions use jump labels. > > Obviously some functions may use more than one jump label so this isn't > exactly bulletproof math. But it gives a rough idea of how widespread > they are. It looks scary. I just wonder why we have never met this problem during last few years. My only guess is that most of these functions are either in core kernel or in code that we do not livepatch. I do not want to say that we should ignore it. I want to understand the cost and impact of the various approaches. Regards, Petr