From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792651607; b=P9JrokGOseDpUESYtNBuWEztfe5aHN/qiuOwCCrEWY1l+dQBk9UX8rhXRZymsyQj6zpa GUg8kul82OuplgYQxBGt+TXQxS5wmtdHizfJBDnYZOsOqSucKY9SMldJ7vj0P3N8hbto4 LsRssDBzWdzdP6DnIyhU4Iuc90Nb0dehAx3Ya/6fRUaxfTuhhMrDURoyGUK62spykPTK6 upTAizEefz6vsT3EpFLqKephGp4Z8Ict3tYG2hqpIFrrsXdgS7lFFkvT7rXpvPXRLzWpe 0avicEOZlet0tzx3ca18USkCEEUhD5N6G0JZascPBEe2DcvLsVAMNYNmUktn57yw7zw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792651607; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received: X-Received:Received:Message-ID:Subject:From:To:Cc:Date:In-Reply-To: References:Autocrypt:Content-Type:Content-Transfer-Encoding: User-Agent:MIME-Version; bh=TKtpG0ZG3GV7aCNX13qQJC+OLUZxo8z1O02EgwHPjyE=; b=xSzDaYA9Mm4oQfZ6iFuaUyp8lQzZ8VNz76plh1poSHOoYY9NV/eJe/TdceQIlPFAFka8 5pfg93KRreNobu+1ogxplKSoh1scmECMvYQu3y8bk9vNmepgMZx1wf88SM5UWkYiEDrwl SwEn6dsJCoUTtALdTLz1UbJ4gb88DlBCQS2OKhqi4Xs5YgUdcsgbb0PPG3Oen7xiP+ud8 6vNxI9e9Xr2zFVb49LmMUwi5/fUVvTh3LXik6WFyVDWYD5XGVg3YOTWgIMwJbn3UPbyJd KsZaSWBfGe1DG+aESxb2/wHZ85d+G5eP5VsROq8x5oKzomZYUlGv6Eit1HiZ+kgaRNQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fMI5v+Bn; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=Y3BfEey6; arc=none smtp.remote-ip=170.10.129.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DEC86606A32E for ; Thu, 22 Oct 2026 06:46:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org DEC86606A32E Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fMI5v+Bn; dkim=pass (2048-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=Y3BfEey6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792651606; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=TKtpG0ZG3GV7aCNX13qQJC+OLUZxo8z1O02EgwHPjyE=; b=fMI5v+Bn9trqXkvWKIV78QHC9NDmRLqsK+4DvqyZM58VfIskk3jHLoGtCu2fejjfDb5z/g 8ZwBeMvpSgM2obqHNUiGPrK8/vPRJZSx+WXtY40Q7nTzeSNsTGNUgUIvVCbNJVSlg5brhN eLYHeB9Qy8j7AHaP4YtPX4GDyeJre94= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-495-R0HAphsvOCOtMlnkEC92sw-1; Thu, 22 Oct 2026 06:46:44 +0000 X-MC-Unique: R0HAphsvOCOtMlnkEC92sw-1 X-Mimecast-MFC-AGG-ID: R0HAphsvOCOtMlnkEC92sw_1792651603 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-48e00f3929bso365737f8f.0 for ; Wed, 21 Oct 2026 23:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1792651603; x=1793256403; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :autocrypt:references:in-reply-to:date:cc:to:from:subject:message-id :from:to:cc:subject:date:message-id:reply-to:content-type; bh=TKtpG0ZG3GV7aCNX13qQJC+OLUZxo8z1O02EgwHPjyE=; b=Y3BfEey6N8msn+41QVUavFWYnbJoP4nREg7/9BXIXfXA+yFBO7Kc8oWI8t0tOiAUSc DUKHMPiA0TK1mm3k6Z5rWF3HWbMoszgyVz3zJL8f8fMdnxG/yvi6nIdiEBpJx+oxbyYa e5/qoazr8OrWoiXBh4kcsrAH4123p2AHgWGd7hGDymRp/b9gsnCYRJ187wCqAlja6PRJ SAl53I6dLPNgkPqj4ezSRVwj3UZBjPMFAdl6GXR20iPa/elcrj+F1cAZgnO9HlSBVJaT gn1a8HEnCwZPnCq9dDhwhUhap9xs15HdKipE4O5GmUdTKhPpEDeyYX2kcMSCsYtqj7c1 REDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792651603; x=1793256403; h=mime-version:user-agent:content-transfer-encoding:content-type :autocrypt:references:in-reply-to:date:cc:to:from:subject:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=TKtpG0ZG3GV7aCNX13qQJC+OLUZxo8z1O02EgwHPjyE=; b=lX8ei/PNSJtjOAaBcDJtNDEZ9cVcb0GgdFUY2kI3QQAljhip4I5Qvq87YJCWU2w9tO kirsJBfYBYsoUmzWQpbSv2M3EtC94UXSo+nE7tZp3tAMVznBBpg7FvqtIy9t5vVVE+Cm jDYlngWBq8UGqkuHPiR55WsZqPe+7uz9Rj7fzccHNt5Lma1nXWMh8Al9EgJOhefAwuff XPedeWk3qtjuXR0CRr2cPd/gr4y3loeShasHNGWJKB9rmwxIEc8ZB1IYJFXf/s4H4q9N Dpc8QFYp5vpU66zU+fOZY2Fwsc0vnP8F785fRVDmstvOXZ1gydyEcCF91HqMPMk7mIp8 2FUw== X-Forwarded-Encrypted: i=1; AKwUvBxGQks6NauTmVmUz402IrScz9AzDOK6PRYrvJmL/nmZf/BryWopqbUBX7UcfBvS7V7e+TlDSWdnxKDd5b8=@vger.kernel.org X-Gm-Message-State: AFq9FYL3++eWmQxnrTRFSCrq18ooJn2A6zcPu3e1DWUeX8YN8rp2zSgC MQnv1RzoXKBmTG1vNW58H+ZdROZSp4emjFhTvgIqhBoviqK1po6nnbCSEiwLw/1HCOVK4528B0T f4DU9DPnVjM0lKr954KsNrzAEusbjtLfL9r4P6alAPSC2+uat+VFq0Z5MqrCY2zRrTw== X-Gm-Gg: AYBFou2l5sOZLbq5HIAe3sOUaSIOmKUE62zMWhvNT94kjB6SrxjwicGcO9wLd9h6T7I RHoSLxjnPHOeUaRhZi75v2lNXfs7rdmCVy2NPd2tCaRoPJUjpKKxQu/AaxKD4VLVWKSHkrGNvVY yGAFnbHXs55FtNmKwO6gzDfwKOKxCr8t+Llck43+aE85UhHWWJM93TEN3AeFQ/qaMvcFrm0q9lo 2vinZdm2N2LvLVVxkNIoccOgs7t+kE87hKtkIqoTu+7T1dvFZR41L3L0qC6Cmo+IOrsm5CvqG3r 77flxVX5DqPYGpeabd1zmjp5GXcdcfHePL8kjY3FI4F+EzejTiUg9gXRcR+OJq/TyEOsPPrhgTG gSx9c3qWV+gDCuoUpT9AnVRA43z02 X-Received: by 2002:a05:6000:4b11:b0:48c:54ec:ea3 with SMTP id ffacd0b85a97d-48e2d24e4acmr3010779f8f.13.1792651603109; Wed, 21 Oct 2026 23:46:43 -0700 (PDT) X-Received: by 2002:a05:6000:4b11:b0:48c:54ec:ea3 with SMTP id ffacd0b85a97d-48e2d24e4acmr3010732f8f.13.1792651602647; Wed, 21 Oct 2026 23:46:42 -0700 (PDT) Received: from gmonaco-thinkpadt14gen3.rmtit.csb ([195.174.133.173]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e25840115sm10061810f8f.48.2026.10.21.23.46.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 23:46:42 -0700 (PDT) Message-ID: Subject: Re: [PATCH v2 10/15] tools/rv: Add BPF monitors From: Gabriele Monaco To: John Ogness , Steven Rostedt Cc: Nam Cao , Tomas Glozar , Alexei Starovoitov , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, Wen Yang , Tobias Schaffner , Viktor Malik Date: Thu, 22 Oct 2026 08:46:40 +0200 In-Reply-To: <87h5ifvw3p.fsf@jogness.linutronix.de> References: <20261001152042.124445-1-gmonaco@redhat.com> <878q3xtptq.fsf@jogness.linutronix.de> <8B3FF026-6159-48CF-8FEA-AF2FACD2E4EB@redhat.com> <87bj8s8ih9.fsf@jogness.linutronix.de> <87v770uuyr.fsf@jogness.linutronix.de> <87ik2zryzo.fsf@jogness.linutronix.de> <0055967d4571e7c8549dfa476fa6b15b93013701.camel@redhat.com> <8580176d216258e9008c344e0529509117dcc18b.camel@redhat.com> <87pkx5q1w4.fsf@jogness.linutronix.de> <0d4f11b1999588ddba9d855db43fc492eda32de1.camel@redhat.com> <87h5ifqy6w.fsf@yellow.woof> <20261021094853.29b9f7be@gandalf.local.home> <87h5ifvw3p.fsf@jogness.linutronix.de> Autocrypt: addr=gmonaco@redhat.com; prefer-encrypt=mutual; keydata=mDMEZuK5YxYJKwYBBAHaRw8BAQdAmJ3dM9Sz6/Hodu33Qrf8QH2bNeNbOikqYtxWFLVm0 1a0JEdhYnJpZWxlIE1vbmFjbyA8Z21vbmFjb0BrZXJuZWwub3JnPoiZBBMWCgBBFiEEysoR+AuB3R Zwp6j270psSVh4TfIFAmjKX2MCGwMFCQWjmoAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgk Q70psSVh4TfIQuAD+JulczTN6l7oJjyroySU55Fbjdvo52xiYYlMjPG7dCTsBAMFI7dSL5zg98I+8 cXY1J7kyNsY6/dcipqBM4RMaxXsOtCRHYWJyaWVsZSBNb25hY28gPGdtb25hY29AcmVkaGF0LmNvb T6InAQTFgoARAIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgBYhBMrKEfgLgd0WcK eo9u9KbElYeE3yBQJoymCyAhkBAAoJEO9KbElYeE3yjX4BAJ/ETNnlHn8OjZPT77xGmal9kbT1bC1 7DfrYVISWV2Y1AP9HdAMhWNAvtCtN2S1beYjNybuK6IzWYcFfeOV+OBWRDQ== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-2.fc44) X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 On Wed, 2026-10-21 at 18:53 +0206, John Ogness wrote: > On 2026-10-21, Gabriele Monaco wrote: > > > BTW, I'm curious if it isn't possible to keep both in-kernel and BPF > > > monitors? That is, for those cases that do not change often and has a > > > well known model, to simply keep those as modules and hard coded. > >=20 > > In my opinion it is possible and I'm designing every change with that > > coexistence in mind. > >=20 > > I would say we could only drop in-kernel if BPF does such a great job > > to cover every single technical and non-technical requirement or > > use-case, AND if it makes maintaining the whole thing easier. >=20 > I am wondering if coexistence should be the goal. For example, the > monitor classes (DA, LTL, HTA) are only implemented in the kernel and > provide kfuncs for the state transition functions to be available to BPF > monitors. I would expect that this would allow BPF monitors to have the > full functionality as in-kernel monitors, since the events, errors, and > reactors would all trigger from the monitor class code. Well, this would be yet another hybrid requiring BPF monitors registration = in the kernel like I proposed in the RFC [1], which was the main point of contention (that fully shared reactors and sysfs interface, by the way). For this I would argue, though, that such monitors would be BPF just on pap= er, we wouldn't be able to use many advantages BPF provides (e.g. BPF maps). The current implementation already shares the header with in-kernel monitor= s, so the actual logic is shared. What isn't shared is the storage type and some = glue around it. I used BPF maps because they offer some nice flexibility especially around = per- task and per-obj monitors. On top of using more battle tested code. I would like to keep that. Besides, we'd need to be extra careful on controlling the callers. Right no= w handlers are static, so it's easier to make sure no rogue caller messes up = with monitoring. What else definitely isn't shared, which is the main point of this whole conversation, is trace events. Those could be kfuncs. And no matter what you do, BPF monitors will need to share the trace events (unlike in-kernel that have separate events per moni= tor). In short, I don't think this would be easy to achieve and wouldn't earn us = that much. (Plus I'd lose the hardly earned Alexei's blessing ;) ) What do you think? Gabriele [1] - https://lore.kernel.org/lkml/20260831090524.106845-1-gmonaco@redhat.c= om