Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp2080979ybp; Thu, 10 Oct 2019 01:51:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqyBI12mYqEwd3UgV2vdPqOiTap+5HHU58W44BgRpUJxXgZ7pg00lEhZzaNjEZ+qU+rWuSo8 X-Received: by 2002:aa7:c603:: with SMTP id h3mr7020946edq.44.1570697470609; Thu, 10 Oct 2019 01:51:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570697470; cv=none; d=google.com; s=arc-20160816; b=hFx8QZQMQB+fpPLaCaYMcvAPCcw/r7qWKurYu0WcVM9pLh5/iAPVHhXCjhLZ56I8aj PXe1ZTguTB0RTJM+DNfs6aNWIP+TP6wIt/wJXLJuiwQUqhJUUgApg+XQMfljcgvv2A9J 9X9TDVMu69OGLnayIwPzyLHaRFxbwUwsq4dOV5cjIDXUsyrLWBE/o/mUsfP5/01REl4J h3lvL+E61XpNSIqdGtLiS/0iPnpi3q+xaibHNwKobA9/xh+DvxsLtPfWgD+gOa7aYjdc bBdhu2fquhY5LPX+oVH5WJBQvDp4Lq5zeyt1558eMPAIfUClFgNKwLbt5NW4FoIOygIq /Ppw== 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=Us1Dv6CfbO2OYA8qHyU2xD5j65061+/wyCDmHJB1EQU=; b=TIkeKGbMj10kSqvxgPCoQn7+SwpaBCAi7iygQ6Y/FJ1V8Fy0Id43wLL8YHNCx+38Z6 JtXVtUNVaTLwsmfUgwAg/sW8f8ckgnQe9zv/E0Y/HOx9Lcys0wVAzWUujATp459mH09H 95t3Z5zB0Hthai1EnwGOGrJjWGpx158hNal08K/48IXn1yFvPCK5Ps8dLvw608R6Lssm EBBAcx1/+mklwjdGZ9SJd/PUTj+7XShlOdy42tZ37dB5PBsod+nSpz19suLiotOebDVm YNuqgvJVgWkh3IA2t2ea5Rhz+bc77Y2t5lt28yiWU+wgcKTgjSo2GSZw2gvrwOj7lfQV 6ksQ== 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 d5si2712050edq.60.2019.10.10.01.50.47; Thu, 10 Oct 2019 01:51:10 -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 S2390017AbfJJIun (ORCPT + 99 others); Thu, 10 Oct 2019 04:50:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:44292 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2390001AbfJJIuh (ORCPT ); Thu, 10 Oct 2019 04:50:37 -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 E6965AD7B; Thu, 10 Oct 2019 08:50:35 +0000 (UTC) Date: Thu, 10 Oct 2019 10:50:35 +0200 From: Petr Mladek To: Steven Rostedt Cc: jikos@kernel.org, Joe Lawrence , jpoimboe@redhat.com, mingo@redhat.com, Miroslav Benes , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [PATCH 0/3] ftrace: Introduce PERMANENT ftrace_ops flag Message-ID: <20191010085035.emsdks6xecazqc6k@pathway.suse.cz> References: <20191007081714.20259-1-mbenes@suse.cz> <20191008193534.GA16675@redhat.com> <20191009112234.bi7lvp4pvmna26vz@pathway.suse.cz> <20191009102654.501ad7c3@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191009102654.501ad7c3@gandalf.local.home> 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 Wed 2019-10-09 10:26:54, Steven Rostedt wrote: > Petr Mladek wrote: > I think Joe's approach is much easier to understand and implement. The > "ftrace_enabled" is a global flag, and affects all things ftrace (the > function bindings). What this patch was doing, was what you said. Make > ftrace_enabled only affect the ftrace_ops without the "PERMANENT" flag > set. But that is complex and requires a bit more accounting in the > ftrace system. Something I think we should try to avoid. From my POV, the fact that livepatches make use of ftrace handlers is just an implementation detail. Ideally, users should not know about it. The livepatch handlers should be handled special way and should not be affected by the ftrace sysfs interface. And ideally, the ftrace sysfs interface should still be available for other ftrace users. I would understand if this would be too complicated and we would need to find a compromise. > What we are now proposing, is that if "ftrace_enabled" is not set, the > register_ftrace_function() will fail if the ftrace_ops passed to it has > the PERMANENT flag set (which would cause live patching to fail to > load). From the livepatch point of view it would be more reliable if ftrace_ops with PERMANENT flag would force "ftrace_enabled" to be always true. It will make the flag unusable for other ftrace users. But it will be already be the case when it can't be disabled. Best Regards, Petr