Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2013237pxb; Thu, 16 Sep 2021 23:24:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEzs3YAFlho7hG8y/vn3IJdEunh9CRLxq424zdxIubutmNcbqhqKEno6a6gYzvu1H4gZzg X-Received: by 2002:a05:6e02:921:: with SMTP id o1mr6385087ilt.289.1631859858083; Thu, 16 Sep 2021 23:24:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631859858; cv=none; d=google.com; s=arc-20160816; b=fi/fmxV/u+0YGIIBBtJb5p5Kgv1wPd4vGRrYPe2Xg0jjiHcL3gTqw0ZjtRWNu8QhYz v95KA9SXGDpYq2xj2yd5x5j9B/m85UTRokyuTzZjPlHuMCnJqG1tUtmMrKGoOm7OD9QU Gzwt92zRBDRoqVpvXTHd19g6/7Bu0DNpXyOGREVEZW2aHk+HZNwYsL9iJsAZPZIYlItk vHjBJdBNyK6Vk8BFFbndbCNCBtbvl2376liFwxsON9woktwDXJD8B3Epd5WWPS5Y+Pq0 nGL2oo4ebd9uPvs/ktk1KXVwmlxmKUamDIHe2KDV9FOVJ59S/a+pnE3R1srv0rIc2Rd3 69Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=sDj5QquE5wN5sDynUMGxIuSMd5cPh1XI9LhK8+3NFac=; b=xWcYI7ZaAPh4c8pfM8jv9lSXZgaWhdi5kpYyUQbD2jthsjLAATE8Gl9vr85+kTLN8k 5JUHdV1vJH4dEAJBmYzaqdjXzQoclg8o4iLktGkDpGNs/qw2vlscH4jy2ZQv4mDR1Zeh LrOaUDjw/HKkxj3/x1ZlRcCDda79E0ca9dwDN80kwAw99dhnq/tiMzDVpRprWyru1NUC i4mUnvf1E2UALK8gMKQ7nam4qMQBRojFmlSVuIeuOvyQ/IqsCI0rfik65AfV3j7I7bsF 9o527DRKCAWCwKvGe3zP4LtGnVA+oFtdHAREeiMxsGdAo58lMzXsbEBru8MoV1Vam75v UpMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SvRPDXSf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n5si2569225iob.93.2021.09.16.23.24.07; Thu, 16 Sep 2021 23:24:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SvRPDXSf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234938AbhIPTvD (ORCPT + 99 others); Thu, 16 Sep 2021 15:51:03 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:59811 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233659AbhIPTvC (ORCPT ); Thu, 16 Sep 2021 15:51:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631821781; 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: in-reply-to:in-reply-to:references:references; bh=sDj5QquE5wN5sDynUMGxIuSMd5cPh1XI9LhK8+3NFac=; b=SvRPDXSfyyw3YkAJxpKab/Ao4qdMlbudhtwz7F6qjNaBlRs9LKIhQFJ3MP1hltVTQcKnlF Zgrm/CQXTgj4KaOMR8fyt/Sn93oLRZ1bbLbAy7j+oBSjTGTYTkEqhXugzpYl4Ehn2oFeUc W0ZveLFCXih25P6NyQoNbCtynvihv6k= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-321-CDEg18dnP_yqK5gMxfb7ng-1; Thu, 16 Sep 2021 15:49:40 -0400 X-MC-Unique: CDEg18dnP_yqK5gMxfb7ng-1 Received: by mail-wr1-f71.google.com with SMTP id m18-20020adfe952000000b0015b0aa32fd6so2839635wrn.12 for ; Thu, 16 Sep 2021 12:49:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sDj5QquE5wN5sDynUMGxIuSMd5cPh1XI9LhK8+3NFac=; b=nz5YiS5Y7nkvYQMiFDv8e2jDQlqMMfmb2WxMqBZin1uRp9eHR00/hznCQqwzjqdoA+ 1c5GIIhpUpuZB/c7LFp49oVdccRkkylb9gvCFcdiOIAaiOcfbN60xoNS8//NtxYoEnYk ipGCuqTD6oheFyoVC+0dTmq0Q15oBdApzbDsK9SsY7sPm5QIwZMPBb4JsFZOgPy3tjBM kvQwY24L8EkmVDuI5G/6/twEzXF4TFvJ78u7YXIHKkVMzNf0/W+EViYFnVvVFGe7r+vU qZkigkcooE5g8Xr5qogpcDYklrsOND+li+LSkNf6nMxtaeF8q8dFZoSqvneAEReoFN5Y Lu4Q== X-Gm-Message-State: AOAM532cO/6N5JkQzL7sKXxHlEXeDUZHGnSorxZZrPfNsU1pQEcCpN+j SnjbnqS200hCe+GeOmO79TWrrfCoCGHN8e/OkxHcvQeQ9AFMnd7lDVQfha4DzJUkbXPB6CJ3x+P O3r6zfMWU1jk5WBcdkQooRDQy X-Received: by 2002:a7b:c005:: with SMTP id c5mr6900964wmb.59.1631821779044; Thu, 16 Sep 2021 12:49:39 -0700 (PDT) X-Received: by 2002:a7b:c005:: with SMTP id c5mr6900949wmb.59.1631821778833; Thu, 16 Sep 2021 12:49:38 -0700 (PDT) Received: from krava ([83.240.63.48]) by smtp.gmail.com with ESMTPSA id n186sm8475826wme.31.2021.09.16.12.49.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 12:49:38 -0700 (PDT) Date: Thu, 16 Sep 2021 21:49:37 +0200 From: Jiri Olsa To: Steven Rostedt Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko Subject: Re: [PATCH 7/8] ftrace: Add multi direct modify interface Message-ID: References: <20210831095017.412311-1-jolsa@kernel.org> <20210831095017.412311-8-jolsa@kernel.org> <20210914174134.1d8fd944@oasis.local.home> <20210915174718.77acaf8b@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210915174718.77acaf8b@gandalf.local.home> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 15, 2021 at 05:47:18PM -0400, Steven Rostedt wrote: > On Tue, 14 Sep 2021 17:41:34 -0400 > Steven Rostedt wrote: > > > A better solution, that prevents having to do this, is to first change > > the function fentry's to call the ftrace list loop function, that calls > > the ftrace_ops list, and will call the direct call via the ops in the > > loop. Have the ops->func call the new direct function (all will be > > immediately affected). Update the entries, and then switch from the > > loop back to the direct caller. > > An easy way to force the loop function to be called instead of the direct > trampoline, is to register a stub ftrace_ops to each of the functions that > the direct function attaches to. You can even share the hash in doing so. > > Having the ftrace_ops attached in the same locations as the direct > trampoline, will force the loop function to be called (to call the stub > ftrace_ops as well as the direct trampoline ftrace_ops helper). > > Then change the direct trampoline address, which will have the ftrace_ops > helper use that direct trampoline immediately*. Then when you remove the > ftrace_ops stub, it will update all the call sites to call the new direct > trampoline directly. ok, that's the way the current direct modify interface is using, right? I thought it'd be not so easy to adopt for multiple functions, I'll check on that again and come for help ;-) > > (*) not quite immediately, as there's no read memory barrier with the > direct helper, so it may still be calling the old trampoline. But this > shouldn't be an issue. If it is, then you would need to include some memory > barrier synchronization. > > I'm curious to what the use case is for the multi direct modify interface > is? when the trampoline is re-generated by adding or removing program, we have same functions to trace and new trampoline to attach thanks, jirka > > -- Steve >