From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7A64C43331 for ; Fri, 6 Sep 2019 12:51:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8115320678 for ; Fri, 6 Sep 2019 12:51:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404760AbfIFMvR (ORCPT ); Fri, 6 Sep 2019 08:51:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:35376 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2404746AbfIFMvR (ORCPT ); Fri, 6 Sep 2019 08:51:17 -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 70B34AFB0; Fri, 6 Sep 2019 12:51:15 +0000 (UTC) Date: Fri, 6 Sep 2019 14:51:01 +0200 (CEST) From: Miroslav Benes To: Josh Poimboeuf cc: Joe Lawrence , Petr Mladek , jikos@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal In-Reply-To: <20190905125418.kleis5ackvhtn4hs@treble> Message-ID: References: <20190814151244.5xoaxib5iya2qjco@treble> <20190816094608.3p2z73oxcoqavnm4@pathway.suse.cz> <20190822223649.ptg6e7qyvosrljqx@treble> <20190823081306.kbkm7b4deqrare2v@pathway.suse.cz> <20190826145449.wyo7avwpqyriem46@treble> <5c649320-a9bf-ae7f-5102-483bc34d219f@redhat.com> <20190905023202.ed7fecc22xze4pwj@treble> <20190905125418.kleis5ackvhtn4hs@treble> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Now, I don't think that replacing .ko on disk is a good idea. We've > > already discussed it. It would lead to a maintenance/packaging problem, > > because you never know which version of the module is loaded in the > > system. The state space grows rather rapidly there. > > What exactly are your concerns? > > Either the old version of the module is loaded, and it's livepatched; or > the new version of the module is loaded, and it's not livepatched. Let's have module foo.ko with function a(). Live patch 1 (LP1) fixes it to a'(), which calls new function b() (present in LP1). LP1 is used only if foo.ko is loaded. foo.ko is replaced with foo'.ko on disk. It contains both a'() (fixed a() to be precise) and new b(). Now there is LP2 with new function c() (or c'(), it does not matter) calling b(). Either foo.ko or foo'.ko can be loaded and you don't know which one. The implementation LP2 would be different in both cases. You could say that it does not matter. If LP2 is implemented for foo.ko, the same could work for foo'.ko (b() would be a part of LP2 and would not be called directly from foo'.ko). LP2 would only be necessarily larger. It is true in case of functions, but if symbol b is not a function but a global variable, it is different then. Moreover, in this case foo'.ko is "LP superset". Meaning that it contains only fixes which are present in LP1. What if it is not. We usually preserve kABI, so there could be a module in two or more versions compiled from slightly different code (older/newer and so on) and you don't know which one is loaded. To be fair we don't allow it (I think) at SUSE except for KMPs (kernel module packages) (the issue of course exists even now and we haven't solved it yet, because it is rare) and out of tree modules which we don't support with LP. It could be solved with srcversion, but it complicates things a lot. "blue sky" idea could extend the issue to all modules given the above is real. Does it make sense? Miroslav