Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Song Liu <songliubraving@fb.com>
To:     Steven Rostedt <rostedt@goodmis.org>
CC:     Song Liu <song@kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "bpf@vger.kernel.org" <bpf@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "ast@kernel.org" <ast@kernel.org>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        "andrii@kernel.org" <andrii@kernel.org>,
        Kernel Team <Kernel-team@fb.com>,
        "jolsa@kernel.org" <jolsa@kernel.org>,
        "mhiramat@kernel.org" <mhiramat@kernel.org>
Subject: Re: [PATCH v2 bpf-next 1/5] ftrace: allow customized flags for
 ftrace_direct_multi ftrace_ops
Thread-Topic: [PATCH v2 bpf-next 1/5] ftrace: allow customized flags for
 ftrace_direct_multi ftrace_ops
Thread-Index: AQHYdriN/yOd0MaY7kCCLNeAHt/+qa19MFsAgAAO2fGAAAd7gIAAEfYA
Date:   Thu, 14 Jul 2022 01:42:59 +0000
Message-ID: <C2FCCC9B-5F7D-4BBF-8410-67EA79166909@fb.com>
References: <20220602193706.2607681-1-song@kernel.org>
 <20220602193706.2607681-2-song@kernel.org>
 <20220713191846.18b05b43@gandalf.local.home>
 <0029EF24-6508-4011-B365-3E2175F9FEAB@fb.com>
 <20220713203841.76d66245@rorschach.local.home>
In-Reply-To: <20220713203841.76d66245@rorschach.local.home>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QUHselXhsC2XjkLGSds8dVEVFRo2JLxOGymCbL7ZH+itcUIZGRcdPzB1wPPB?=
 =?us-ascii?Q?+oVzh3zyQ30Md5zBNV0wzLulu3nXjGD9D4Ww/5STrQe6NPPBC0M3nuYZ6nre?=
 =?us-ascii?Q?1UnlvzsFaTyXanrRfsfAoOz9u2KP9espxpPXVkRrG/7ivMyfxCOxf0qnUhXp?=
 =?us-ascii?Q?KttaQJGJvngxNp/vqGILnhu76yLyYQIvxddmRE6aN4BL2RBoytpgsD5uGp0D?=
 =?us-ascii?Q?nABTqdavdEMjd0uDqt98OqsKmAVTEx0ZpnuF7UGMy2gBZZL8omGh2c0O8zmL?=
 =?us-ascii?Q?xjqCpNVaN/qLBWt3FTVIq0WRQG6wfCY8hRY5nrASsEk/J0Ug7FysShOFARFy?=
 =?us-ascii?Q?zznq6R+1I+ct/VY5mzLaPAkphy1POldP5HcMLA5m8Ag5DMe9K2upmVPFHEDX?=
 =?us-ascii?Q?y6zfmU/vdxc3jFeokyftJh0ak56OB2MC/qOn0v5MpA3ZE2mh9LdpzdIS7RSM?=
 =?us-ascii?Q?kT7ScKUNwFETAYpC2Z/kekify3BI7EAQBxvTnxvFiO0EfPwdXrtsJj8AC5kx?=
 =?us-ascii?Q?wVppUQoLpxuo76AmtqewnZTIYJwQ/zukZQ0es6M5mZF1yi0QmsByE5UMADvQ?=
 =?us-ascii?Q?01M17JgRFBA5NsYsnwkUyb9kwipav7uihtjYg1g+PXCfltS/ZJiRojLLzLO5?=
 =?us-ascii?Q?GFlDYqxKxmfeTdyLgQx7nO7qxVMKKBWh3Tkw4+DYAzqfQ62aZBi6lsaBeneY?=
 =?us-ascii?Q?uHGPmjku4yioVaIUy8D6rsQmkW8dMQ0o+YS3qGsKi9HWJ1LTEhKjfAyQPMaS?=
 =?us-ascii?Q?zt7Yh39P2bl+afOm+SR/4WlA2oTVwb1ePyjxc8K1oPPXAQvk8HYSkxbpoiFB?=
 =?us-ascii?Q?WG3Ddi/8IEEj8xBv+w5PFDiQlvsNTrjjrL/wWeac8xozHjMkVIsQCwtbsbXP?=
 =?us-ascii?Q?dkqajpPB7fQzqed8dU0bpcCQ1/Yhdhs/mAdaG4qVT28ytAwzq7QlWOAUM6cB?=
 =?us-ascii?Q?9EQfc6f6UB+1mjwB1N9R7DQg3SlmQOKnEQd2Ycxwnsp27f1zdaAD21629RLP?=
 =?us-ascii?Q?f2d3efaMNVqIl9ijWFBCK61mwAnBkbU/+Qjw/nybuZlNcJz5It3lMGaMuHpt?=
 =?us-ascii?Q?Bd3b+JvFmD5gTeSfZukA+Yj6RV9te+ZtRFoydmZvKx6xaYTqe1P1SsmgFMsv?=
 =?us-ascii?Q?ZQlIQ+l5zF1z5pcKC3c1X995vK/LYUoTQ/VvrjYiA7MgcfdJvMVLUtfpGtO1?=
 =?us-ascii?Q?ztzC80k7CY1nJWf+YTcyjIKSiuY3FrcosKrk6z65jOsdtzFeITIGURxQLZSO?=
 =?us-ascii?Q?cO8rgvF01DVH/rke/y/AhnLrCMJMobwoCWKSo70Ut8tDCmleWN7VX/51z/HI?=
 =?us-ascii?Q?V69LgiNVmiYtJJ8+6WGb5xEbvyxINPIykIuEWW225AKtNfDuzUXN8kql1RnP?=
 =?us-ascii?Q?YkjoOBv/pJA10f/5p+aTT1jjmq30Qs6BEMY/fdmEqNMAesJCP6oMliH0R/xV?=
 =?us-ascii?Q?2Dzl/ekwgwfXl4681huksUiPT8a/IT0hm67FjPK2K2gWykSSeirXBeB/p3Na?=
 =?us-ascii?Q?I3kPeDVywN/bOwD97Wz5cueMKE0gX2V6VvbfTiIOhjOsPkFh/zwfemNQNqxo?=
 =?us-ascii?Q?xJ+/yLt4udMcPNOh1rnm/CZuFtk9QgTbMP6PsmjMid1ITVj60jvve7jNVj78?=
 =?us-ascii?Q?W6LRfU3MASRuxdYtSqXlsB0=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F1C6D3841DA5214389D01B411B0CB64D@namprd15.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: fb.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR15MB5109.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5685112e-0306-439b-7256-08da653a2ee8
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2022 01:42:59.5371
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 80rK0SkkvF2aQEVqBSvBFyuUJsnnKArkHSD6VF33ffYCvdO++/0jwNG21bL19dm3T5Bl4YYL5bfSjSyq4w/N5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR1501MB2052
X-Proofpoint-ORIG-GUID: lc3_UUzc1igA2FwR5vSHMWkC4MihMcWK
X-Proofpoint-GUID: lc3_UUzc1igA2FwR5vSHMWkC4MihMcWK
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1
 definitions=2022-07-13_13,2022-07-13_03,2022-06-22_01
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Jul 13, 2022, at 5:38 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> On Thu, 14 Jul 2022 00:11:53 +0000
> Song Liu <songliubraving@fb.com> wrote:
> 
>>> That is, can we register a direct function with this function and pick a
>>> function with IPMODIFY already attached?  
>> 
>> Yes, if the direct function follows regs->ip, it works. 
>> 
>> For example, BPF trampoline with only fentry calls will just work with only this patch.
> 
> I replied with my thoughts on this to patch 3, but I disagree with this.
> 
> ftrace has no idea if the direct trampoline modifies the IP or not.
> ftrace must assume that it does, and the management should be done in
> the infrastructure.
> 
> As I replied to patch 3, here's my thoughts.
> 
> DIRECT is treated as though it changes the IP. If you register it to a
> function that has an IPMODIFY already set to it, it will call the
> ops->ops_func() asking if the ops can use SHARED_IPMODIFY (which means
> a DIRECT can be shared with IPMODIFY). If it can, then it returns true,
> and the SHARED_IPMODIFY is set *by ftrace*. The user of the ftrace APIs
> should not have to manage this. It should be managed by the ftrace
> infrastructure.

Hmm... I don't think this gonna work. 

First, two IPMODIFY ftrace ops cannot work together on the same kernel 
function. So there won't be a ops with both IPMODIFY and SHARE_IPMODIFY. 

non-direct ops without IPMODIFY can already share with IPMODIFY ops.
Only direct ops need SHARE_IPMODIFY flag, and it means "I can share with 
another ops with IPMODIFY". So there will be different flavors of 
direct ops:

  1. w/ IPMODIFY, w/o SHARE_IPMODIFY;
  2. w/o IPMODIFY, w/o SHARE_IPMODIFY;
  3. w/o IPMODIFY, w/ SHARE_IPMODIFY. 

#1 can never work on the same function with another IPMODIFY ops, and 
we don't plan to make it work. #2 does not work with another IPMODIFY 
ops. And #3 works with another IPMODIFY ops. 

The owner of the direct trampoline uses these flags to tell ftrace 
infrastructure the property of this trampoline. 

BPF trampolines with only fentry calls are #3 direct ops. BPF 
trampolines with fexit or fmod_ret calls will be #2 trampoline by 
default, but it is also possible to generate #3 trampoline for it.
 
BPF side will try to register #2 trampoline, If ftrace detects another 
IPMODIFY ops on the same function, it will let BPF trampoline know 
with -EAGAIN from register_ftrace_direct_multi(). Then, BPF side will 
regenerate a #3 trampoline and register it again. 

I know this somehow changes the policy with direct ops, but it is the
only way this can work, AFAICT. 

Does this make sense? Did I miss something?

Thanks,
Song