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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 86B67C4727C for ; Thu, 1 Oct 2020 12:44:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3CEF4208B6 for ; Thu, 1 Oct 2020 12:44:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732016AbgJAMoA convert rfc822-to-8bit (ORCPT ); Thu, 1 Oct 2020 08:44:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:54366 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731952AbgJAMoA (ORCPT ); Thu, 1 Oct 2020 08:44:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 95C68AD85; Thu, 1 Oct 2020 12:43:59 +0000 (UTC) From: Nicolai Stange To: Evgenii Shatokhin Cc: Miroslav Benes , live-patching@vger.kernel.org, pmladek@suse.com, nstange@suse.de Subject: Re: Patching kthread functions References: <9c9e5b82-660e-a666-b55c-a357dd7482cb@virtuozzo.com> Date: Thu, 01 Oct 2020 14:43:58 +0200 In-Reply-To: (Miroslav Benes's message of "Thu, 1 Oct 2020 13:13:07 +0200 (CEST)") Message-ID: <87lfgqt8tt.fsf@suse.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: live-patching@vger.kernel.org Miroslav Benes writes: > On Wed, 30 Sep 2020, Evgenii Shatokhin wrote: >> Is that so? Are there any workarounds? > > Petr, do you remember the crazy workarounds we talked about? My head is > empty now. And I am sure, Nicolai could come up with something. There might be some clever tricks ycou could play, but that depends on the diff you want to turn into a livepatch. For example, sometimes it's possible to livepatch a callee and make it trick the unpatchable caller into the desired behaviour. However, in your case it might be easier to simply kill the running kthread and start it again, e.g. from a ->post_patch() callback. Note that KLP's callbacks are a bit subtle though, at a minimum you'd probably also want to implement ->pre_unpatch() to roll everything back and perhaps also disable (->replace) downgrades by means of the klp_state API. You can find some good docs on callbacks and klp_state at Documentation/livepatch/. Thanks, Nicolai -- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Felix Imendörffer