Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF

From: Jiri Kosina <jikos@kernel.org>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Hans de Goede <hdegoede@redhat.com>,
	 ksummit@lists.linux.dev
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF
Date: Thu, 23 Jun 2022 22:15:17 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.YFH.7.76.2206232215020.14340@cbobk.fhfr.pm> (raw)
In-Reply-To: <CAO-hwJJ=9oNXA+mX9r=DwyUxbvf5-gWxAzBRCrbqdLd1LbPQdg@mail.gmail.com>

On Tue, 21 Jun 2022, Benjamin Tissoires wrote:

> > I'm currently at the Open Source Summit, and Dirk basically asked my
> > question almost verbatim to Linus (during the "Dirk and Linus show").
> 
> Heh, interesting :)

I guess that also sort of underlines the point that this discussion is 
relevant :)

> Hmm, OK, but I am not sure we are all talking about the same thing here.
> 
> For real user space applications using eBPF, AFAICT, today we have 
> cgroups and network filtering. And for those 2 applications, given that 
> there is a well defined eBPF API, it wouldn't surprise me that 
> maintainers should take care of the user space breakage.
> 
> However, if I decide to attach a random BPF program to random functions 
> in the kernel without any involvement in the kernel, and use it to get 
> some metrics, how can we consider this to be plain debugging or an 
> actual user space application (assuming I share it with the rest of the 
> world)?
> 
> So IMO, we can not assume that any user space application relying on 
> eBPF should never break if that application is hooking to random 
> functions in the kernel. If that user space application is using a well 
> defined (not-an-)API, then yes, this is something maintainers should be 
> aware of.

And we have been exactly here with traceevents/tracepoints, as far as I 
can tell.

It was introduced mostly for debugging and profiling purposes. Then some 
random Joe Developer wrote his 'ubertrace' tracing tool that had hard 
dependency on format of some of those, and they they changed, this 
publicly available tool broke. I don't see how eBPF makes this in 
principle different, and that's exactly why I brought this up. Because 
every maintainer is potentially involved/affected, even those who have no 
idea whatsoever yet what eBPF is.

> > This still does not address the problem. First, where's the line where a
> > tool becomes something for normal users?
> 
> I thought this was the initial topic that Jiri raised, and why we need
> to have this discussion :)

Absolutely, yes.

Thanks,

-- 
Jiri Kosina
SUSE Labs