* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF @ 2022-06-15 6:55 Jiri Kosina 2022-06-15 8:05 ` Linus Walleij 2022-06-15 18:35 ` Luis Chamberlain 0 siblings, 2 replies; 28+ messages in thread From: Jiri Kosina @ 2022-06-15 6:55 UTC (permalink / raw) As everyone is pretty much aware, eBPF adoption is quickly expanding for various usecases in the kernel. For example, there has recently been effort invested into adding eBPF support to HID subsystem [1], in order to make adding quirks for specific devices easier, not requiring a "full" proper driver for devices that just need a tiny bit of special handling here and there but apart from that can be handled by the generic driver just fine. While there are many proponents of "eBPF is good for everything and your grandma" aproach, this opinion is not universally shared. One big risk is that this will eventually lead to possibility of having whole drivers / core code written in eBPF, which could potentially lead to decreased maintainability and supportability, also due to big fragmentation of the code (eBPF programs might not necessarily be shipped together with the kernel codebase). This could potentially be a big risk for distros as well, as we (as a distro vendor) might be very quickly losing control over what is actually running in the context of the kernel they are bound to be supporting. In the specific case of drivers, there also is also some similarity in principle with UDI, which is a concept that hasn't proved viable quite some time ago already :) I feel like we are currently lacking a clear borderline, defining what is still acceptable by the community to be implemented in terms of eBPF, and what is over the line as it'd be causing big supportability and maintainability concerns (see e.g. Christoph's concern to the HID eBPF implementation implications [2]). So I'd like to propose a session where we'd ideally converge closer to defining a borderline between acceptable and non-acceptable usecases for eBPF in the kernel. [1] https://lore.kernel.org/all/20220518205924.399291-1-benjamin.tissoires@redhat.com/ [2] https://lore.kernel.org/all/YoX7iHddAd4FkQRQ@infradead.org/ Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-15 6:55 [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF Jiri Kosina @ 2022-06-15 8:05 ` Linus Walleij 2022-06-15 8:36 ` Jiri Kosina 2022-06-15 18:35 ` Luis Chamberlain 1 sibling, 1 reply; 28+ messages in thread From: Linus Walleij @ 2022-06-15 8:05 UTC (permalink / raw) On Wed, Jun 15, 2022 at 8:55 AM Jiri Kosina <jkosina@suse.cz> wrote: > As everyone is pretty much aware, eBPF adoption is quickly expanding for > various usecases in the kernel. For example, there has recently been > effort invested into adding eBPF support to HID subsystem [1], in order to > make adding quirks for specific devices easier, not requiring a "full" > proper driver for devices that just need a tiny bit of special handling > here and there but apart from that can be handled by the generic driver > just fine. I see your concern as subsystem maintainer not wanting HID to turn into a dumping ground for various vendor extensions. I submitted a Razer keyboard bling driver that was nixed with "put it in userspace", i.e. using hidraw, and I was directed to the project called "razertest" https://github.com/z3ntu/razer_test https://patchwork.kernel.org/project/linux-input/patch/20181128222443.13062-1-linus.walleij@linaro.org/ One of the concerns raised was (Luca) "I wouldn't put too much functionality into the kernel driver as new devices are being released all the time and it would probably take very long for those patches to arrive at users of non-rolling distros." The problem with this is that while the kernel has a highway into *all* distros and how many distros even carry "razer_test"? Not Fedora for example. That surely has not reached users of any distro AFAICT. So what we have here is three prominent HID contributors: Benjamin, Luca and Jiri. One of you work for RedHat and one of you work for SuSE. And yet none of your distributions have packaged Luca's userspace project? Can't you see that this isn't working? I feel HID is maybe missing the point that creating new userspace projects is really hard and resource-craving, involving a lot of social problem, process and lobbying compared to maintaining a few more driver files in the kernel. Referring people to misc half-adopted userspace projects for full support of the hardware on their desk isn't really sustainable, no matter if they use eBPF or not. (Asking them to go and create their own userspace driver extension libraries is even less helpful.) I once created libmtp for MTP communication with storage devices such as all Android phones. In a way it is a success since it is deployed in all distros and even used on Mac by Google for accessing Android devices. Would I implement it today I would seriously discuss with Greg to make this a kernel driver instead. Simply because the kernel has more momentum, community and attention. More bugs get fixed there, maintenance actually happens. I'm really suspicious of other microkernel-like projects such as libsane and cups as well, but they can talk for themselves. To me the big question is rather: does HID have a working userspace project community outside of the kernel, which is adopted by all major distributions? I know it is a chicken and egg problem, and that you need to create something to get accepted but is there some momentum in these projects? At a minimum, do what Bartosz did for the libgpiod library that we (reluctantly) developed for userspace GPIO access, and put the git for the userspace on git.kernel.org so people know where to find it and get the cuddly feeling that it has something to do with the official Linux kernel. > While there are many proponents of "eBPF is good for everything and your > grandma" aproach, this opinion is not universally shared. One big risk is > that this will eventually lead to possibility of having whole drivers / > core code written in eBPF, which could potentially lead to decreased > maintainability and supportability, also due to big fragmentation of the > code (eBPF programs might not necessarily be shipped together with the > kernel codebase). (...) > I feel like we are currently lacking a clear borderline, defining what is > still acceptable by the community to be implemented in terms of eBPF, and > what is over the line as it'd be causing big supportability and > maintainability concerns (see e.g. Christoph's concern to the HID eBPF > implementation implications [2]). I must say from my own experience I side with Christoph here. I just want to add some code to the kernel so my hardware works (better) out of the box, is that really so voluminous for the HID maintainers to maintain that it need to be referred to userspace? I kind of feel like rebasing and resubmitting my razer driver from 2018 to raise a discussion here. Will I be asked to rewrite it in eBPF if I do? Yours, Linus Walleij ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-15 8:05 ` Linus Walleij @ 2022-06-15 8:36 ` Jiri Kosina 2022-06-15 17:04 ` Jan Kara [not found] ` <CAO-hwJJmW_STS=nT22n4pcaZf9gz953K4o2vhgmq-ig4OzxOLg@mail.gmail.com> 0 siblings, 2 replies; 28+ messages in thread From: Jiri Kosina @ 2022-06-15 8:36 UTC (permalink / raw) On Wed, 15 Jun 2022, Linus Walleij wrote: > > As everyone is pretty much aware, eBPF adoption is quickly expanding for > > various usecases in the kernel. For example, there has recently been > > effort invested into adding eBPF support to HID subsystem [1], in order to > > make adding quirks for specific devices easier, not requiring a "full" > > proper driver for devices that just need a tiny bit of special handling > > here and there but apart from that can be handled by the generic driver > > just fine. > > I see your concern as subsystem maintainer not wanting HID to turn into > a dumping ground for various vendor extensions. Just to clarify the point I was trying to make here -- I am not saying that I do not like this particular case (i.e. the HID-BFP patchset that Benjamin is developing). My point was that unless we properly define what are the reasonable usecases for eBPF and what is the borderline beyond which we shouldn't go if we want to maintain sanity of the ecosystem (and people having to support the kernels :) ), we will be getting this discussion popping up over and over again. > I submitted a Razer keyboard bling driver that was nixed with "put it in > userspace", i.e. using hidraw, and I was directed to the project called > "razertest" https://github.com/z3ntu/razer_test > https://patchwork.kernel.org/project/linux-input/patch/20181128222443.13062-1-linus.walleij@linaro.org/ > > One of the concerns raised was (Luca) "I wouldn't put too much functionality > into the kernel driver as new devices are being released all the time and it > would probably take very long for those patches to arrive at users of > non-rolling distros." I actually don't buy that as an argument. Distros are quite happily backporting to their kernels whatever the users / customers request from them, so I don't see why this would be an exception. If there is a good use for it in a particular distro, it's up to that distro (or embedded vendor kernel) to have it ported. > The problem with this is that while the kernel has a highway into *all* > distros and how many distros even carry "razer_test"? Not Fedora > for example. That surely has not reached users of any distro AFAICT. > > So what we have here is three prominent HID contributors: Benjamin, > Luca and Jiri. One of you work for RedHat and one of you work for SuSE. > And yet none of your distributions have packaged Luca's userspace project? > Can't you see that this isn't working? I am probably much more inclined into taking the drivers into kernel than some of the others. I have always had issues with drivers in userspace (no matter whether it's libusb, UIO, hidraw, or whatever else there is), exactly because of the issues it brings when it comes to distributing it. With perhaps an exception of things that can be made to work with an udev rule / script. > To me the big question is rather: does HID have a working userspace > project community outside of the kernel, which is adopted by all major > distributions? I know it is a chicken and egg problem, and that you need > to create something to get accepted but is there some momentum in these > projects? Even though I brought HID as an example on which I wanted to just demonstrate the point, I'd actually like to propose this discussion to stay completely abstracted away from any particular subsystem. I didn't bring it up because of HID specifically, but as a general issue that spans across subsystems. > > While there are many proponents of "eBPF is good for everything and your > > grandma" aproach, this opinion is not universally shared. One big risk is > > that this will eventually lead to possibility of having whole drivers / > > core code written in eBPF, which could potentially lead to decreased > > maintainability and supportability, also due to big fragmentation of the > > code (eBPF programs might not necessarily be shipped together with the > > kernel codebase). > (...) > > I feel like we are currently lacking a clear borderline, defining what is > > still acceptable by the community to be implemented in terms of eBPF, and > > what is over the line as it'd be causing big supportability and > > maintainability concerns (see e.g. Christoph's concern to the HID eBPF > > implementation implications [2]). > > I must say from my own experience I side with Christoph here. > > I just want to add some code to the kernel so my hardware works (better) > out of the box, is that really so voluminous for the HID maintainers to > maintain that it need to be referred to userspace? > > I kind of feel like rebasing and resubmitting my razer driver from 2018 > to raise a discussion here. I actually don't remember that submission from back 2018, sorry, but I personally wouldn't see a big problem accepting the driver as-is. But that's a discussion to have on a regular thread after you (re)submit it, but is probably not so relevant for the point I wanted to make here. > Will I be asked to rewrite it in eBPF if I do? Definitely not by me :) Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-15 8:36 ` Jiri Kosina @ 2022-06-15 17:04 ` Jan Kara 2022-06-15 17:25 ` Jonathan Corbet [not found] ` <CAO-hwJJmW_STS=nT22n4pcaZf9gz953K4o2vhgmq-ig4OzxOLg@mail.gmail.com> 1 sibling, 1 reply; 28+ messages in thread From: Jan Kara @ 2022-06-15 17:04 UTC (permalink / raw) On Wed 15-06-22 10:36:41, Jiri Kosina wrote: > On Wed, 15 Jun 2022, Linus Walleij wrote: > > > > As everyone is pretty much aware, eBPF adoption is quickly expanding for > > > various usecases in the kernel. For example, there has recently been > > > effort invested into adding eBPF support to HID subsystem [1], in order to > > > make adding quirks for specific devices easier, not requiring a "full" > > > proper driver for devices that just need a tiny bit of special handling > > > here and there but apart from that can be handled by the generic driver > > > just fine. > > > > I see your concern as subsystem maintainer not wanting HID to turn into > > a dumping ground for various vendor extensions. > > Just to clarify the point I was trying to make here -- I am not saying > that I do not like this particular case (i.e. the HID-BFP patchset that > Benjamin is developing). > > My point was that unless we properly define what are the reasonable > usecases for eBPF and what is the borderline beyond which we shouldn't go > if we want to maintain sanity of the ecosystem (and people having to > support the kernels :) ), we will be getting this discussion popping up > over and over again. Yeah. Related to this is the fact that this way eBPF hooks become de-facto API of the kernel with all the implications for required stability. It is one thing to use eBPF for kernel introspection / monitoring (there occasional breakage is kind of expected by userspace) and another to enable hardware with it where people just expect things to work... Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-15 17:04 ` Jan Kara @ 2022-06-15 17:25 ` Jonathan Corbet [not found] ` <20220615174601.GX1790663@paulmck-ThinkPad-P17-Gen-1> [not found] ` <20220615174358.GA26358@lst.de> 0 siblings, 2 replies; 28+ messages in thread From: Jonathan Corbet @ 2022-06-15 17:25 UTC (permalink / raw) Jan Kara <jack@suse.cz> writes: > Yeah. Related to this is the fact that this way eBPF hooks become de-facto > API of the kernel with all the implications for required stability. It is > one thing to use eBPF for kernel introspection / monitoring (there > occasional breakage is kind of expected by userspace) and another to enable > hardware with it where people just expect things to work... Relevant to this whole thing, I think, is the multigenerational LRU discussion at LSFMM: https://lwn.net/Articles/894859/ One aspect that was only dropped in as a response to a question is that the plan is to add a BPF hook to manage the movement of pages between LRU generations; this will be done because nobody really knows how to come up with an optimal solution to that problem for the general case. That's about as core as it gets and, if users are tweaking memory management with BPF, that will surely achieve ABI status in short order. Beyond that, though, is the temptation to say "we don't have to figure out this hard problem, we'll just add a BPF hook and let the users find a solution for themselves". The line between providing a useful means for expert users to optimize their systems and skipping out on our own duty to optimize things is not always clear, at least to me. jon ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <20220615174601.GX1790663@paulmck-ThinkPad-P17-Gen-1>]
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF [not found] ` <20220615174601.GX1790663@paulmck-ThinkPad-P17-Gen-1> @ 2022-06-15 18:25 ` Jiri Kosina 2022-06-16 16:26 ` Steven Rostedt 0 siblings, 1 reply; 28+ messages in thread From: Jiri Kosina @ 2022-06-15 18:25 UTC (permalink / raw) On Wed, 15 Jun 2022, Paul E. McKenney wrote: > > Relevant to this whole thing, I think, is the multigenerational LRU > > discussion at LSFMM: https://lwn.net/Articles/894859/ > > > > One aspect that was only dropped in as a response to a question is that > > the plan is to add a BPF hook to manage the movement of pages between > > LRU generations; this will be done because nobody really knows how to > > come up with an optimal solution to that problem for the general case. > > That's about as core as it gets and, if users are tweaking memory > > management with BPF, that will surely achieve ABI status in short order. > > > > Beyond that, though, is the temptation to say "we don't have to figure > > out this hard problem, we'll just add a BPF hook and let the users find > > a solution for themselves". The line between providing a useful means > > for expert users to optimize their systems and skipping out on our own > > duty to optimize things is not always clear, at least to me. > > I might as well ask the naive question: Should subsystems document > which hooks they intend to treat as ABI? ;-) Unfortunately, this "just select a subset" aproach has been proven not to work with tracepoints (which is exactly why some subsytems systematically refused to add tracepoints in the first place, because they explicitly did want to avoid being constrained by tracepoints having to be stable), which in this particular aspect is a similar problem. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-15 18:25 ` Jiri Kosina @ 2022-06-16 16:26 ` Steven Rostedt 2022-06-16 16:38 ` James Bottomley 0 siblings, 1 reply; 28+ messages in thread From: Steven Rostedt @ 2022-06-16 16:26 UTC (permalink / raw) On Wed, 15 Jun 2022 20:25:41 +0200 (CEST) Jiri Kosina <jikos@kernel.org> wrote: > > I might as well ask the naive question: Should subsystems document > > which hooks they intend to treat as ABI? ;-) I would like there to be a decree that eBPF is denoted as the same as a fancy module. And be treated the same as modules. That is, there is NO ABI! A eBPF program that works on one kernel should have no guarantee that it will work on another version of the kernel. Because eBPF is basically just that, a module. It is compiled into native code that runs in kernel space. Exactly like a module, with the caveat that it must first go through a verifier. > > Unfortunately, this "just select a subset" aproach has been proven not to > work with tracepoints (which is exactly why some subsytems systematically > refused to add tracepoints in the first place, because they explicitly did > want to avoid being constrained by tracepoints having to be stable), which > in this particular aspect is a similar problem. The difference between eBPF and tracepoints (actually only trace events), is that trace events are exported visibly to user space and attached via the perf system call. The trace event's format is shown in the tracefs events directory. Just like any file in /proc, the trace events can easily be read by a privileged user space application. Now tracepoints are not exported to user space. The difference between a tracepoint and trace event is that a tracepoint is the "trace_foo()" in the kernel, where as the trace event is the data extracted from the tracepoint via the TRACE_EVENT() macro and listed in the format files in the tracefs events directory. The tracepoint interface is just like any other C function in the kernel, and should never be considered an ABI. I wanted to bring this up at MS as well, so I'd like to extend this topic, and say eBPF programs *are* modules. We had an issue [1] that we added a parameter to the sched_switch tracepooint (not trace event), and that broke some eBPF programs. Since all they wanted was for use to reorder the parameters of the tracepoint call, we obliged. But we made it a point that this must not set a precedent. The mere fact that we had to do this has brought up major concerns that eBPF is starting to become too invasive and may limit the ability of kernel development. [1] https://lore.kernel.org/all/c8a6930dfdd58a4a5755fc01732675472979732b.camel@fb.com/T/#mc2ec6eded478552fc01d10e32dc4a892f95a9900 -- Steve ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-16 16:26 ` Steven Rostedt @ 2022-06-16 16:38 ` James Bottomley 2022-06-16 16:51 ` Steven Rostedt 0 siblings, 1 reply; 28+ messages in thread From: James Bottomley @ 2022-06-16 16:38 UTC (permalink / raw) On Thu, 2022-06-16 at 12:26 -0400, Steven Rostedt wrote: > On Wed, 15 Jun 2022 20:25:41 +0200 (CEST) > Jiri Kosina <jikos@kernel.org> wrote: > > > > I might as well ask the naive question: Should subsystems > > > document > > > which hooks they intend to treat as ABI? ;-) > > I would like there to be a decree that eBPF is denoted as the same as > a fancy module. And be treated the same as modules. That is, there is > NO ABI! Well, you can wish for a Pony, but there's no guarantee you'll get one ... > > A eBPF program that works on one kernel should have no guarantee that > it will work on another version of the kernel. Because eBPF is > basically just that, a module. It is compiled into native code that > runs in kernel space. Exactly like a module, with the caveat that it > must first go through a verifier. Based on the encouragement we gave as kernel developers, certain tracing as a service companies that previously had propritary modules (Sysdig for instance) are now moving over to using tracing with eBPF. At the time we thought this was good for the kernel; if we now try to tell them "actually you can't use the interface because it's completely unstable" that's going to undermine our whole argument to them for dumping proprietary modules. So I don't think no eBPF at all is stable is a tenable position for us. Equally well, I don't think it's as hard as a userspace ABI meaning it can never change. I think we can get away with changes that force tracing and other value added service providers to change their eBPF, I just don't think we can do it very often without damaging the value of eBPF over proprietary modules. > > Unfortunately, this "just select a subset" aproach has been proven > > not to work with tracepoints (which is exactly why some subsytems > > systematically refused to add tracepoints in the first place, > > because they explicitly did want to avoid being constrained by > > tracepoints having to be stable), which in this particular aspect > > is a similar problem. As I said above, I think we have to provide *some* stability, but for a sophisticated consumer it doesn't have to be the absolute stability guarantee of an ABI. I think we should debate what kinds of slightly unstable stability we could provide James ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-16 16:38 ` James Bottomley @ 2022-06-16 16:51 ` Steven Rostedt 2022-06-16 18:25 ` James Bottomley 0 siblings, 1 reply; 28+ messages in thread From: Steven Rostedt @ 2022-06-16 16:51 UTC (permalink / raw) On Thu, 16 Jun 2022 12:38:24 -0400 James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > A eBPF program that works on one kernel should have no guarantee that > > it will work on another version of the kernel. Because eBPF is > > basically just that, a module. It is compiled into native code that > > runs in kernel space. Exactly like a module, with the caveat that it > > must first go through a verifier. > > Based on the encouragement we gave as kernel developers, certain > tracing as a service companies that previously had propritary modules > (Sysdig for instance) are now moving over to using tracing with eBPF. I wasn't in this conversation, so I'm unaware of the advantages of it. > At the time we thought this was good for the kernel; if we now try to > tell them "actually you can't use the interface because it's completely > unstable" that's going to undermine our whole argument to them for > dumping proprietary modules. So I don't think no eBPF at all is stable > is a tenable position for us. > > Equally well, I don't think it's as hard as a userspace ABI meaning it > can never change. I think we can get away with changes that force > tracing and other value added service providers to change their eBPF, I > just don't think we can do it very often without damaging the value of > eBPF over proprietary modules. Perhaps we should add a place in tools/bpf for "upstream bpf programs". Or is there already something there? Again, I would like to treat bpf no different than modules. Sorry, I don't see a "convince proprietary module folks to create proprietary bpf programs" as progress. If anything, it's going backwards. If you want a "stable ebpf program" then you submit it upstream and we can make sure that it works with any internal API changes, the same way we do for modules. Those with out-of-tree modules will have the technical debt of changing every time a new kernel release is out, and so should out-of-tree bpf programs. > > > > Unfortunately, this "just select a subset" aproach has been proven > > > not to work with tracepoints (which is exactly why some subsytems > > > systematically refused to add tracepoints in the first place, > > > because they explicitly did want to avoid being constrained by > > > tracepoints having to be stable), which in this particular aspect > > > is a similar problem. > > As I said above, I think we have to provide *some* stability, but for a > sophisticated consumer it doesn't have to be the absolute stability > guarantee of an ABI. I think we should debate what kinds of slightly > unstable stability we could provide What you define as "somewhat stable" others may define as "not stable at all". There is no happy medium (as you said, "you can wish for a Pony, but there's no guarantee you'll get one"). Once you say you will have some stability, that will become an albatross around your neck forever. -- Steve ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-16 16:51 ` Steven Rostedt @ 2022-06-16 18:25 ` James Bottomley 2022-06-16 19:08 ` Steven Rostedt 2022-06-17 7:53 ` Jiri Kosina 0 siblings, 2 replies; 28+ messages in thread From: James Bottomley @ 2022-06-16 18:25 UTC (permalink / raw) On Thu, 2022-06-16 at 12:51 -0400, Steven Rostedt wrote: > On Thu, 16 Jun 2022 12:38:24 -0400 > James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > A eBPF program that works on one kernel should have no guarantee > > > that it will work on another version of the kernel. Because eBPF > > > is basically just that, a module. It is compiled into native code > > > that runs in kernel space. Exactly like a module, with the caveat > > > that it must first go through a verifier. > > > > Based on the encouragement we gave as kernel developers, certain > > tracing as a service companies that previously had propritary > > modules (Sysdig for instance) are now moving over to using tracing > > with eBPF. > > I wasn't in this conversation, so I'm unaware of the advantages of > it. Unaware of the advantages of using eBPF over proprietary modules? We've had a long standing policy of discouraging proprietary modules. We use the carrot and stick methods. The stick is definitely the API is unstable and changes often and will break you (and even some kernel developers will go out of their way to change the API your using). The carrot is showing them there are better and easier ways of doing the things they're trying to achieve without using proprietary modules. > > At the time we thought this was good for the kernel; if we now try > > to tell them "actually you can't use the interface because it's > > completely unstable" that's going to undermine our whole argument > > to them for dumping proprietary modules. So I don't think no eBPF > > at all is stable is a tenable position for us. > > > > Equally well, I don't think it's as hard as a userspace ABI meaning > > it can never change. I think we can get away with changes that > > force tracing and other value added service providers to change > > their eBPF, I just don't think we can do it very often without > > damaging the value of eBPF over proprietary modules. > > Perhaps we should add a place in tools/bpf for "upstream bpf > programs". Or is there already something there? Again, I would like > to treat bpf no different than modules. Sorry, I don't see a > "convince proprietary module folks to create proprietary bpf > programs" as progress. If anything, it's going backwards. That's a false dichotomy: it's not true the only way of forcing openness is to pull something into the kernel tree. I gave the proprietary module as one example, but not everything that uses eBPF is proprietary ... although it is also true that not everything that's open is under a licence compatible with the kernel. > If you want a "stable ebpf program" then you submit it upstream and > we can make sure that it works with any internal API changes, the > same way we do for modules. Those with out-of-tree modules will have > the technical debt of changing every time a new kernel release is > out, and so should out-of-tree bpf programs. Assuming eBPF takes off, that would have some poor maintainer managing the whole of the compatibility changes for the entire eBPF ecosystem ... I really don't think that's scalable. > > > > Unfortunately, this "just select a subset" aproach has been > > > > proven not to work with tracepoints (which is exactly why some > > > > subsytems systematically refused to add tracepoints in the > > > > first place, because they explicitly did want to avoid being > > > > constrained by tracepoints having to be stable), which in this > > > > particular aspect is a similar problem. > > > > As I said above, I think we have to provide *some* stability, but > > for a sophisticated consumer it doesn't have to be the absolute > > stability guarantee of an ABI. I think we should debate what kinds > > of slightly unstable stability we could provide > > What you define as "somewhat stable" others may define as "not stable > at all". There is no happy medium (as you said, "you can wish for a > Pony, but there's no guarantee you'll get one"). > > Once you say you will have some stability, that will become an > albatross around your neck forever. Not if it's managed correctly. One method could simply be to not care but be careful. After all, lots of companies still manage to produce proprietary modules even with us actively trying to break the API. Either it's not as difficult as we think or API changes are easier to cope with than we assume. James ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-16 18:25 ` James Bottomley @ 2022-06-16 19:08 ` Steven Rostedt 2022-06-17 7:53 ` Jiri Kosina 1 sibling, 0 replies; 28+ messages in thread From: Steven Rostedt @ 2022-06-16 19:08 UTC (permalink / raw) On Thu, 16 Jun 2022 14:25:44 -0400 James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > Not if it's managed correctly. One method could simply be to not care > but be careful. After all, lots of companies still manage to produce > proprietary modules even with us actively trying to break the API. > Either it's not as difficult as we think or API changes are easier to > cope with than we assume. All I read from this is that eBPF is the new way that proprietary modules can have their stable API. The problem I have here is that eBPF is becoming extremely invasive. It is now hooking to any function in the kernel that isn't marked notrace. If there's not a clear border on what is considered non-stable now, we will be fighting with those that say "hey this broke my bpf program, revert it please" for a long time coming. -- Steve ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-16 18:25 ` James Bottomley 2022-06-16 19:08 ` Steven Rostedt @ 2022-06-17 7:53 ` Jiri Kosina 2022-06-17 8:24 ` Linus Walleij 2022-06-17 10:30 ` Jan Kara 1 sibling, 2 replies; 28+ messages in thread From: Jiri Kosina @ 2022-06-17 7:53 UTC (permalink / raw) On Thu, 16 Jun 2022, James Bottomley wrote: > > If you want a "stable ebpf program" then you submit it upstream and > > we can make sure that it works with any internal API changes, the > > same way we do for modules. Those with out-of-tree modules will have > > the technical debt of changing every time a new kernel release is > > out, and so should out-of-tree bpf programs. > > Assuming eBPF takes off, that would have some poor maintainer managing > the whole of the compatibility changes for the entire eBPF ecosystem > ... I really don't think that's scalable. I nevertheless still see this as the best and only option we have; that is, have an infrastructure in the kernel tree for maintaining eBPF programs, somehow sorted per subsystem so that it mirrors the standard maintainership / subsystem structure proper, and have the maintainers responsible for keeping the eBPF programs related to their subsystem in sync with the internal changes happening in the subsystem. At the end of the day, it will be the subsystem maintainers themsleves accepting the program into the tree in the first place, so it's not like they are receiving responsibility for something they never wanted in the first place. So we'll probably end up with subsystems with many eBPF programs, and also subsystems with zero. Similarly to tracepoints. I.e. pretty much the 'perf' model, but on much wider scale (as eBPF can hook to just about anything). Any other option seems to lead to having eBPF programs sprinkled all over the internet that depend on particular kernel version / API, leading to nothing else than unhappy users, because "I downloaded it, it didn't work, Linux sucks". -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-17 7:53 ` Jiri Kosina @ 2022-06-17 8:24 ` Linus Walleij 2022-06-17 10:30 ` Jan Kara 1 sibling, 0 replies; 28+ messages in thread From: Linus Walleij @ 2022-06-17 8:24 UTC (permalink / raw) On Fri, Jun 17, 2022 at 9:54 AM Jiri Kosina <jikos@kernel.org> wrote: > On Thu, 16 Jun 2022, James Bottomley wrote: > > > > If you want a "stable ebpf program" then you submit it upstream and > > > we can make sure that it works with any internal API changes, the > > > same way we do for modules. Those with out-of-tree modules will have > > > the technical debt of changing every time a new kernel release is > > > out, and so should out-of-tree bpf programs. > > > > Assuming eBPF takes off, that would have some poor maintainer managing > > the whole of the compatibility changes for the entire eBPF ecosystem > > ... I really don't think that's scalable. > > I nevertheless still see this as the best and only option we have; that > is, have an infrastructure in the kernel tree for maintaining eBPF > programs, somehow sorted per subsystem so that it mirrors the standard > maintainership / subsystem structure proper, and have the maintainers > responsible for keeping the eBPF programs related to their subsystem in > sync with the internal changes happening in the subsystem. It's similar to what we have for Device Tree bindings already, and those are in many cases handled by the relevant subsystem maintainer, both review and merge. > At the end of the day, it will be the subsystem maintainers themsleves > accepting the program into the tree in the first place, so it's not like > they are receiving responsibility for something they never wanted in the > first place. So we'll probably end up with subsystems with many eBPF > programs, and also subsystems with zero. Similarly to tracepoints. The concern is that as subsystem maintainers had to learn YAML to deal with device tree bindings, they now have to learn eBPF syntax, and there is also Rust in the kernel around the corner to learn. Plenty of languages to learn. Oh well, they keep us on the move. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-17 7:53 ` Jiri Kosina 2022-06-17 8:24 ` Linus Walleij @ 2022-06-17 10:30 ` Jan Kara 2022-06-17 11:04 ` Benjamin Tissoires 1 sibling, 1 reply; 28+ messages in thread From: Jan Kara @ 2022-06-17 10:30 UTC (permalink / raw) On Fri 17-06-22 09:53:52, Jiri Kosina wrote: > On Thu, 16 Jun 2022, James Bottomley wrote: > > > > If you want a "stable ebpf program" then you submit it upstream and > > > we can make sure that it works with any internal API changes, the > > > same way we do for modules. Those with out-of-tree modules will have > > > the technical debt of changing every time a new kernel release is > > > out, and so should out-of-tree bpf programs. > > > > Assuming eBPF takes off, that would have some poor maintainer managing > > the whole of the compatibility changes for the entire eBPF ecosystem > > ... I really don't think that's scalable. > > I nevertheless still see this as the best and only option we have; that > is, have an infrastructure in the kernel tree for maintaining eBPF > programs, somehow sorted per subsystem so that it mirrors the standard > maintainership / subsystem structure proper, and have the maintainers > responsible for keeping the eBPF programs related to their subsystem in > sync with the internal changes happening in the subsystem. > > At the end of the day, it will be the subsystem maintainers themsleves > accepting the program into the tree in the first place, so it's not like > they are receiving responsibility for something they never wanted in the > first place. So we'll probably end up with subsystems with many eBPF > programs, and also subsystems with zero. Similarly to tracepoints. > > I.e. pretty much the 'perf' model, but on much wider scale (as eBPF can > hook to just about anything). > > Any other option seems to lead to having eBPF programs sprinkled all over > the internet that depend on particular kernel version / API, leading to > nothing else than unhappy users, because "I downloaded it, it didn't work, > Linux sucks". OK, but if we keep eBPF programs this closely coupled to the kernel, then what is the advantage of using eBPF, say for HID as was discussed earlier in this thread, compared to just making sure HID has appropriate hooks and the handling of the device quirks is done in normal C code (kernel module) attached to these hooks? Because frankly for me the main value of eBPF over patching and recompiling the kernel is that I can tweak the eBPF code exactly to my needs and load it to the kernel without needing to reboot, over time it is less work than maintaining a source code patch out of tree, and usually it is a hacky tweak I use for some debugging so merging it upstream does not make sense. Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-17 10:30 ` Jan Kara @ 2022-06-17 11:04 ` Benjamin Tissoires [not found] ` <dc6ca88d-d1ef-a1ab-dbef-e9338467271d@redhat.com> 0 siblings, 1 reply; 28+ messages in thread From: Benjamin Tissoires @ 2022-06-17 11:04 UTC (permalink / raw) On Fri, Jun 17, 2022 at 12:31 PM Jan Kara <jack@suse.cz> wrote: > > On Fri 17-06-22 09:53:52, Jiri Kosina wrote: > > On Thu, 16 Jun 2022, James Bottomley wrote: > > > > > > If you want a "stable ebpf program" then you submit it upstream and > > > > we can make sure that it works with any internal API changes, the > > > > same way we do for modules. Those with out-of-tree modules will have > > > > the technical debt of changing every time a new kernel release is > > > > out, and so should out-of-tree bpf programs. > > > > > > Assuming eBPF takes off, that would have some poor maintainer managing > > > the whole of the compatibility changes for the entire eBPF ecosystem > > > ... I really don't think that's scalable. > > > > I nevertheless still see this as the best and only option we have; that > > is, have an infrastructure in the kernel tree for maintaining eBPF > > programs, somehow sorted per subsystem so that it mirrors the standard > > maintainership / subsystem structure proper, and have the maintainers > > responsible for keeping the eBPF programs related to their subsystem in > > sync with the internal changes happening in the subsystem. > > > > At the end of the day, it will be the subsystem maintainers themsleves > > accepting the program into the tree in the first place, so it's not like > > they are receiving responsibility for something they never wanted in the > > first place. So we'll probably end up with subsystems with many eBPF > > programs, and also subsystems with zero. Similarly to tracepoints. > > > > I.e. pretty much the 'perf' model, but on much wider scale (as eBPF can > > hook to just about anything). > > > > Any other option seems to lead to having eBPF programs sprinkled all over > > the internet that depend on particular kernel version / API, leading to > > nothing else than unhappy users, because "I downloaded it, it didn't work, > > Linux sucks". > > OK, but if we keep eBPF programs this closely coupled to the kernel, then > what is the advantage of using eBPF, say for HID as was discussed earlier > in this thread, compared to just making sure HID has appropriate hooks and > the handling of the device quirks is done in normal C code (kernel module) > attached to these hooks? [sorry some of my messages are kept in the moderation queue] This is something I tried to explain in my talk at Kernel Recipes 2 weeks ago [1]. Basically, for regular users, it will be simpler for them to test patches: A developer patches the device through a bpf program, compiles it and sends to the user the source and the bytecode. The user just has to drop the bytecode in the file system and a udev rule automatically loads it without having to reboot the current kernel, making testing way faster and simpler for users. Then developers take the burden of upstreaming the bpf program through the usual email submission. This way users are testing the actual code that is upstreamed without too much hurdle. IMO those kinds of fixes should be in-tree because they are actual fixes. > > Because frankly for me the main value of eBPF over patching and recompiling > the kernel is that I can tweak the eBPF code exactly to my needs and load > it to the kernel without needing to reboot, over time it is less work than > maintaining a source code patch out of tree, and usually it is a hacky > tweak I use for some debugging so merging it upstream does not make sense. > And that's also why I want to give *some* guarantees that the eBPF hooks I am putting in HID are somewhat stable. Or at least I won't break everything at each release and look carefully when there is a change in the API. But these guarantees are just *my* constraints I put on *my* subsystem. I have reasons to believe I can ensure that, so I will. But I am not saying any internal HID function will have ABI guarantees. Only the few hooks I am explicitly documenting as such. So the idea is that your debugging program can live in your own tree, without being submitted, but this is just a contract between myself as a subsystem maintainer and you, not the entire eBPF or ftrace community. I made this so I can put any fancy new kernel API out in eBPF programs, that would be handled by the actual user of that kernel API. If a user wants to set some fancy feature on a particular device, instead of having a kernel parameter that no one will ever use besides that program that may be short-lived, we can then load that functionality with the eBPF program. Or if a user is only interested in a particular event in a report for a device (with the custom protocols some gaming devices are enjoying), then that user can load a BPF program and keep it outside of the tree because the program doesn't make sense without the userspace component. I hope it clarifies a little bit now. For HID at least. Cheers, Benjamin [1] https://kernel-recipes.org/en/2022/talks/hid-bpf/ and https://www.youtube.com/watch?v=nhJqaZT94z0&t=14923s ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <dc6ca88d-d1ef-a1ab-dbef-e9338467271d@redhat.com>]
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF [not found] ` <dc6ca88d-d1ef-a1ab-dbef-e9338467271d@redhat.com> @ 2022-06-17 11:25 ` Benjamin Tissoires 2022-06-17 11:32 ` Hans de Goede 2022-06-20 13:13 ` Steven Rostedt 0 siblings, 2 replies; 28+ messages in thread From: Benjamin Tissoires @ 2022-06-17 11:25 UTC (permalink / raw) On Fri, Jun 17, 2022 at 1:16 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi Benjamin, > > Deliberate offlist reply. [re-adding the list as your last comment] > > On 6/17/22 13:04, Benjamin Tissoires wrote: > > On Fri, Jun 17, 2022 at 12:31 PM Jan Kara <jack@suse.cz> wrote: > >> > >> On Fri 17-06-22 09:53:52, Jiri Kosina wrote: > >>> On Thu, 16 Jun 2022, James Bottomley wrote: > >>> > >>>>> If you want a "stable ebpf program" then you submit it upstream and > >>>>> we can make sure that it works with any internal API changes, the > >>>>> same way we do for modules. Those with out-of-tree modules will have > >>>>> the technical debt of changing every time a new kernel release is > >>>>> out, and so should out-of-tree bpf programs. > >>>> > >>>> Assuming eBPF takes off, that would have some poor maintainer managing > >>>> the whole of the compatibility changes for the entire eBPF ecosystem > >>>> ... I really don't think that's scalable. > >>> > >>> I nevertheless still see this as the best and only option we have; that > >>> is, have an infrastructure in the kernel tree for maintaining eBPF > >>> programs, somehow sorted per subsystem so that it mirrors the standard > >>> maintainership / subsystem structure proper, and have the maintainers > >>> responsible for keeping the eBPF programs related to their subsystem in > >>> sync with the internal changes happening in the subsystem. > >>> > >>> At the end of the day, it will be the subsystem maintainers themsleves > >>> accepting the program into the tree in the first place, so it's not like > >>> they are receiving responsibility for something they never wanted in the > >>> first place. So we'll probably end up with subsystems with many eBPF > >>> programs, and also subsystems with zero. Similarly to tracepoints. > >>> > >>> I.e. pretty much the 'perf' model, but on much wider scale (as eBPF can > >>> hook to just about anything). > >>> > >>> Any other option seems to lead to having eBPF programs sprinkled all over > >>> the internet that depend on particular kernel version / API, leading to > >>> nothing else than unhappy users, because "I downloaded it, it didn't work, > >>> Linux sucks". > >> > >> OK, but if we keep eBPF programs this closely coupled to the kernel, then > >> what is the advantage of using eBPF, say for HID as was discussed earlier > >> in this thread, compared to just making sure HID has appropriate hooks and > >> the handling of the device quirks is done in normal C code (kernel module) > >> attached to these hooks? > > > > [sorry some of my messages are kept in the moderation queue] > > > > This is something I tried to explain in my talk at Kernel Recipes 2 > > weeks ago [1]. > > > > Basically, for regular users, it will be simpler for them to test patches: > > A developer patches the device through a bpf program, compiles it and > > sends to the user the source and the bytecode. The user just has to > > drop the bytecode in the file system and a udev rule automatically > > loads it without having to reboot the current kernel, making testing > > way faster and simpler for users. > > > > Then developers take the burden of upstreaming the bpf program through > > the usual email submission. > > > > This way users are testing the actual code that is upstreamed without > > too much hurdle. > > > > IMO those kinds of fixes should be in-tree because they are actual fixes. > > > > > >> > >> Because frankly for me the main value of eBPF over patching and recompiling > >> the kernel is that I can tweak the eBPF code exactly to my needs and load > >> it to the kernel without needing to reboot, over time it is less work than > >> maintaining a source code patch out of tree, and usually it is a hacky > >> tweak I use for some debugging so merging it upstream does not make sense. > >> > > > > And that's also why I want to give *some* guarantees that the eBPF > > hooks I am putting in HID are somewhat stable. Or at least I won't > > break everything at each release and look carefully when there is a > > change in the API. > > > > But these guarantees are just *my* constraints I put on *my* > > subsystem. I have reasons to believe I can ensure that, so I will. > > > > But I am not saying any internal HID function will have ABI > > guarantees. Only the few hooks I am explicitly documenting as such. > > > > So the idea is that your debugging program can live in your own tree, > > without being submitted, but this is just a contract between myself as > > a subsystem maintainer and you, not the entire eBPF or ftrace > > community. > > > > I made this so I can put any fancy new kernel API out in eBPF > > programs, that would be handled by the actual user of that kernel API. > > I think you need to clarify this, to me it now reads that you want > to use eBPF to implement new APIs, where as what you mean is that > you want to avoid the need to add new APIs like e.g. sysfs knobs > or kernel-module-parameters, right ? Yes. Exactly. It's not about regular and standard API. It's a device specific property/feature that is usually handled through module parameters or custom sysfs entries that have only one single user. > > > If a user wants to set some fancy feature on a particular device, > > instead of having a kernel parameter that no one will ever use besides > > that program that may be short-lived, we can then load that > > functionality with the eBPF program. > > I think you need to clarify here that you mean changing some settings > on the device through e.g. a HID feature report which would require > a sysfs-attribute or kernel-module-parameters without ePBF and you want > to avoid adding more and more sysfs-attributes / kernel-module-parameters? Yep yep :) > > At least I think this is what you are trying to say, and I think that > without some clarification this is not what most kernel-devs will > understand here. Thanks for saying it better than I do :) > > Feel free to copy/paste from this reply to use my attemps at clarifying > things, or just reply to this with the list added back to the Cc :) And done through the lazy option, just forward to the list :) Cheers, Benjamin > > Regards, > > Hans > > > > > Or if a user is only interested in a particular event in a report for > > a device (with the custom protocols some gaming devices are enjoying), > > then that user can load a BPF program and keep it outside of the tree > > because the program doesn't make sense without the userspace > > component. > > > > I hope it clarifies a little bit now. For HID at least. > > > > Cheers, > > Benjamin > > > > [1] https://kernel-recipes.org/en/2022/talks/hid-bpf/ and > > https://www.youtube.com/watch?v=nhJqaZT94z0&t=14923s > > > > _______________________________________________ > > Ksummit-discuss mailing list > > Ksummit-discuss@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-17 11:25 ` Benjamin Tissoires @ 2022-06-17 11:32 ` Hans de Goede 2022-06-20 13:13 ` Steven Rostedt 1 sibling, 0 replies; 28+ messages in thread From: Hans de Goede @ 2022-06-17 11:32 UTC (permalink / raw) Hi, On 6/17/22 13:25, Benjamin Tissoires wrote: > On Fri, Jun 17, 2022 at 1:16 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Hi Benjamin, >> >> Deliberate offlist reply. > > [re-adding the list as your last comment] > >> >> On 6/17/22 13:04, Benjamin Tissoires wrote: >>> On Fri, Jun 17, 2022 at 12:31 PM Jan Kara <jack@suse.cz> wrote: >>>> >>>> On Fri 17-06-22 09:53:52, Jiri Kosina wrote: >>>>> On Thu, 16 Jun 2022, James Bottomley wrote: >>>>> >>>>>>> If you want a "stable ebpf program" then you submit it upstream and >>>>>>> we can make sure that it works with any internal API changes, the >>>>>>> same way we do for modules. Those with out-of-tree modules will have >>>>>>> the technical debt of changing every time a new kernel release is >>>>>>> out, and so should out-of-tree bpf programs. >>>>>> >>>>>> Assuming eBPF takes off, that would have some poor maintainer managing >>>>>> the whole of the compatibility changes for the entire eBPF ecosystem >>>>>> ... I really don't think that's scalable. >>>>> >>>>> I nevertheless still see this as the best and only option we have; that >>>>> is, have an infrastructure in the kernel tree for maintaining eBPF >>>>> programs, somehow sorted per subsystem so that it mirrors the standard >>>>> maintainership / subsystem structure proper, and have the maintainers >>>>> responsible for keeping the eBPF programs related to their subsystem in >>>>> sync with the internal changes happening in the subsystem. >>>>> >>>>> At the end of the day, it will be the subsystem maintainers themsleves >>>>> accepting the program into the tree in the first place, so it's not like >>>>> they are receiving responsibility for something they never wanted in the >>>>> first place. So we'll probably end up with subsystems with many eBPF >>>>> programs, and also subsystems with zero. Similarly to tracepoints. >>>>> >>>>> I.e. pretty much the 'perf' model, but on much wider scale (as eBPF can >>>>> hook to just about anything). >>>>> >>>>> Any other option seems to lead to having eBPF programs sprinkled all over >>>>> the internet that depend on particular kernel version / API, leading to >>>>> nothing else than unhappy users, because "I downloaded it, it didn't work, >>>>> Linux sucks". >>>> >>>> OK, but if we keep eBPF programs this closely coupled to the kernel, then >>>> what is the advantage of using eBPF, say for HID as was discussed earlier >>>> in this thread, compared to just making sure HID has appropriate hooks and >>>> the handling of the device quirks is done in normal C code (kernel module) >>>> attached to these hooks? >>> >>> [sorry some of my messages are kept in the moderation queue] >>> >>> This is something I tried to explain in my talk at Kernel Recipes 2 >>> weeks ago [1]. >>> >>> Basically, for regular users, it will be simpler for them to test patches: >>> A developer patches the device through a bpf program, compiles it and >>> sends to the user the source and the bytecode. The user just has to >>> drop the bytecode in the file system and a udev rule automatically >>> loads it without having to reboot the current kernel, making testing >>> way faster and simpler for users. >>> >>> Then developers take the burden of upstreaming the bpf program through >>> the usual email submission. >>> >>> This way users are testing the actual code that is upstreamed without >>> too much hurdle. >>> >>> IMO those kinds of fixes should be in-tree because they are actual fixes. >>> >>> >>>> >>>> Because frankly for me the main value of eBPF over patching and recompiling >>>> the kernel is that I can tweak the eBPF code exactly to my needs and load >>>> it to the kernel without needing to reboot, over time it is less work than >>>> maintaining a source code patch out of tree, and usually it is a hacky >>>> tweak I use for some debugging so merging it upstream does not make sense. >>>> >>> >>> And that's also why I want to give *some* guarantees that the eBPF >>> hooks I am putting in HID are somewhat stable. Or at least I won't >>> break everything at each release and look carefully when there is a >>> change in the API. >>> >>> But these guarantees are just *my* constraints I put on *my* >>> subsystem. I have reasons to believe I can ensure that, so I will. >>> >>> But I am not saying any internal HID function will have ABI >>> guarantees. Only the few hooks I am explicitly documenting as such. >>> >>> So the idea is that your debugging program can live in your own tree, >>> without being submitted, but this is just a contract between myself as >>> a subsystem maintainer and you, not the entire eBPF or ftrace >>> community. >>> >>> I made this so I can put any fancy new kernel API out in eBPF >>> programs, that would be handled by the actual user of that kernel API. >> >> I think you need to clarify this, to me it now reads that you want >> to use eBPF to implement new APIs, where as what you mean is that >> you want to avoid the need to add new APIs like e.g. sysfs knobs >> or kernel-module-parameters, right ? > > Yes. Exactly. It's not about regular and standard API. It's a device > specific property/feature that is usually handled through module > parameters or custom sysfs entries that have only one single user. > >> >>> If a user wants to set some fancy feature on a particular device, >>> instead of having a kernel parameter that no one will ever use besides >>> that program that may be short-lived, we can then load that >>> functionality with the eBPF program. >> >> I think you need to clarify here that you mean changing some settings >> on the device through e.g. a HID feature report which would require >> a sysfs-attribute or kernel-module-parameters without ePBF and you want >> to avoid adding more and more sysfs-attributes / kernel-module-parameters? > > Yep yep :) > >> >> At least I think this is what you are trying to say, and I think that >> without some clarification this is not what most kernel-devs will >> understand here. > > Thanks for saying it better than I do :) You're welcome. Actually thinking more about this I think this is somewhat akin to Windows HID filter drivers and given BPF-s history in packet-filtering I think that that actually is a helpful analogy to make. Regards, Hans ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-17 11:25 ` Benjamin Tissoires 2022-06-17 11:32 ` Hans de Goede @ 2022-06-20 13:13 ` Steven Rostedt 2022-06-21 15:05 ` Steven Rostedt 1 sibling, 1 reply; 28+ messages in thread From: Steven Rostedt @ 2022-06-20 13:13 UTC (permalink / raw) To: Benjamin Tissoires; +Cc: Hans de Goede, ksummit [ Switched over to ksummit@lists.linux.dev ] On Fri, 17 Jun 2022 13:25:04 +0200 Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote: > > I think you need to clarify here that you mean changing some settings > > on the device through e.g. a HID feature report which would require > > a sysfs-attribute or kernel-module-parameters without ePBF and you want > > to avoid adding more and more sysfs-attributes / kernel-module-parameters? > > Yep yep :) And that is perfectly acceptable, and something I would support. > > > > > At least I think this is what you are trying to say, and I think that > > without some clarification this is not what most kernel-devs will > > understand here. This statement is the issue. There's not a clear line of what constitutes what eBPF is being used for, and worse, what is guaranteed to work across kernel versions. My fear is that we will start having an expectation that pretty much any eBPF program will continue to work, and there's going to be a lot of disgruntled users when it doesn't. Having configuration uses is one thing, enabling full device functionality is another. And anything that touches core interfaces need to be scrutinized. If we look at where BPF came from (iptables et.al.) and having it do nothing more that that but for other parts of the system, it may be a good start. But even that could introduce dependencies of internal kernel implementations that could break over time. Basically, we can try to not break BPF programs but we really need the decree that it's not user API, and does not follow the "don't break user space" agenda, as anything that uses eBPF, is *not* user space. It's just another kind of kernel module. And if an eBPF program does break, if the source of that program is not available, then the answer to fixing it should be "tough luck". This should not be a way for proprietary code to have their kernel API. -- Steve ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-20 13:13 ` Steven Rostedt @ 2022-06-21 15:05 ` Steven Rostedt 2022-06-21 16:33 ` Benjamin Tissoires 0 siblings, 1 reply; 28+ messages in thread From: Steven Rostedt @ 2022-06-21 15:05 UTC (permalink / raw) To: Benjamin Tissoires; +Cc: Hans de Goede, ksummit On Mon, 20 Jun 2022 09:13:44 -0400 Steven Rostedt <rostedt@goodmis.org> wrote: > This statement is the issue. There's not a clear line of what > constitutes what eBPF is being used for, and worse, what is guaranteed > to work across kernel versions. > > My fear is that we will start having an expectation that pretty much > any eBPF program will continue to work, and there's going to be a lot > of disgruntled users when it doesn't. > > Having configuration uses is one thing, enabling full device > functionality is another. And anything that touches core interfaces > need to be scrutinized. > > If we look at where BPF came from (iptables et.al.) and having it do > nothing more that that but for other parts of the system, it may be a > good start. But even that could introduce dependencies of internal > kernel implementations that could break over time. Basically, we can > try to not break BPF programs but we really need the decree that it's > not user API, and does not follow the "don't break user space" agenda, > as anything that uses eBPF, is *not* user space. It's just another kind > of kernel module. > > And if an eBPF program does break, if the source of that program is not > available, then the answer to fixing it should be "tough luck". This > should not be a way for proprietary code to have their kernel API. I'm currently at the Open Source Summit, and Dirk basically asked my question almost verbatim to Linus (during the "Dirk and Linus show"). And Linus stated that there is no defined "API". It's just "do not break user space tools", and this includes eBPF. That is, if something that is useful in user space that breaks with an upgrade, what breaks it either gets reverted, or a "fix" is done to make it work again. Linus specified that when it gets to eBPF programs that do debugging or tracing, or other really low level interactions with the kernel, then if it breaks a user space tool that is doing this low level work, then that's just part of the work flow (fix user space to match, it's already dependent on the kernel implementations). He specified if you break "real user space tools, that normal (non kernel developers) users use" then you need to fix it, regardless if it is using eBPF or not. This still does not address the problem. First, where's the line where a tool becomes something for normal users? Next, eBPF can now attach to pretty much *any* function, and modify how that function operates (changing parameters, etc) Basically, eBPF can do live kernel patching like changes. If a new feature is implemented with eBPF and that eBPF feature depends on some internal kernel implementation, where the maintainer of that code is unaware of this new eBPF implemented feature, if they change their code and break this, then the burden is on the maintainer to fix that breakage, not those that implemented the eBPF feature. This is the worry I have. Maintainers now have no control over what is exposed to users that can become 'user API", aka break normal user tooling, without having a clue that something now depends on the implementation of their code. We really need to take a step back before we let eBPF become fully controlling of anything in the kernel. Because that's going to add a huge burden on maintainers that do not even use eBPF. Exposing information for consumption only is one thing, and what I would like to have more of, but once you allow non-passive interactions with the tracing infrastructure, it changes things where I can see a lot of maintainers will have more push back against the former (reading only tracing, as there's no way to keep it from making changes). -- Steve ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-21 15:05 ` Steven Rostedt @ 2022-06-21 16:33 ` Benjamin Tissoires 2022-06-23 20:15 ` Jiri Kosina 0 siblings, 1 reply; 28+ messages in thread From: Benjamin Tissoires @ 2022-06-21 16:33 UTC (permalink / raw) To: Steven Rostedt; +Cc: Hans de Goede, ksummit On Tue, Jun 21, 2022 at 5:12 PM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Mon, 20 Jun 2022 09:13:44 -0400 > Steven Rostedt <rostedt@goodmis.org> wrote: > > > This statement is the issue. There's not a clear line of what > > constitutes what eBPF is being used for, and worse, what is guaranteed > > to work across kernel versions. > > > > My fear is that we will start having an expectation that pretty much > > any eBPF program will continue to work, and there's going to be a lot > > of disgruntled users when it doesn't. > > > > Having configuration uses is one thing, enabling full device > > functionality is another. And anything that touches core interfaces > > need to be scrutinized. > > > > If we look at where BPF came from (iptables et.al.) and having it do > > nothing more that that but for other parts of the system, it may be a > > good start. But even that could introduce dependencies of internal > > kernel implementations that could break over time. Basically, we can > > try to not break BPF programs but we really need the decree that it's > > not user API, and does not follow the "don't break user space" agenda, > > as anything that uses eBPF, is *not* user space. It's just another kind > > of kernel module. > > > > And if an eBPF program does break, if the source of that program is not > > available, then the answer to fixing it should be "tough luck". This > > should not be a way for proprietary code to have their kernel API. > > 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 :) > > And Linus stated that there is no defined "API". It's just "do not > break user space tools", and this includes eBPF. That is, if something > that is useful in user space that breaks with an upgrade, what breaks > it either gets reverted, or a "fix" is done to make it work again. > > Linus specified that when it gets to eBPF programs that do debugging or > tracing, or other really low level interactions with the kernel, then > if it breaks a user space tool that is doing this low level work, then > that's just part of the work flow (fix user space to match, it's > already dependent on the kernel implementations). He specified if you > break "real user space tools, that normal (non kernel developers) users > use" then you need to fix it, regardless if it is using eBPF or not. 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. I might not win that argument with Linus, but I still prefered your suggestion to make eBPF for drivers similar to kernel modules. > > 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 :) > > Next, eBPF can now attach to pretty much *any* function, and modify how > that function operates (changing parameters, etc) Basically, eBPF can > do live kernel patching like changes. AFAICT, technically, when you attach an TRACING bpf program, you only have read-only capabilities on the arguments. To be able to change the return value, the kernel needs to explicitly export the function as such, and to change the incoming data, well, you need a special kfunc. > > If a new feature is implemented with eBPF and that eBPF feature depends > on some internal kernel implementation, where the maintainer of that > code is unaware of this new eBPF implemented feature, if they change > their code and break this, then the burden is on the maintainer to fix > that breakage, not those that implemented the eBPF feature. I think I would need a more precise example here. kfuncs are by explicitly defined in the kernel, meaning that the eBPF program willing to use that feature needs to go through the kfunc. And then, I would hope that the writer of the kfunc writes selftests for it, and we can detect the change early enough before it gets pushed. So the only other part a maintainer would not be aware of is if the eBPF program attached a tracing program to one of the internal functions, and I don't have a solution for this given that it's already in the wild, and you already had the case once. > > This is the worry I have. Maintainers now have no control over what is > exposed to users that can become 'user API", aka break normal user > tooling, without having a clue that something now depends on the > implementation of their code. > > We really need to take a step back before we let eBPF become fully > controlling of anything in the kernel. Because that's going to add a > huge burden on maintainers that do not even use eBPF. We already have the painful part available to anybody. I have a simple example for the gamepads with a touchpad: I can easily attach a eBPF program that counts how many times a hidraw devnode is opened, and if the result is positive, disable another devnode through the sysfs (the input node of the touchpad) that should not be used at the same time. If I push that code to a userspace tool, let's say Steam or systemd, this will be considered as "application" and I am now preventing the maintainer of hidraw or maybe devnode to not do further changes regarding those functions? So I would rather have a clear definition of what is an eBPF program that is an extension of a driver, and how we can deal with internal kernel changes. > > Exposing information for consumption only is one thing, and what I > would like to have more of, but once you allow non-passive interactions > with the tracing infrastructure, it changes things where I can see a > lot of maintainers will have more push back against the former (reading > only tracing, as there's no way to keep it from making changes). > Again, AFAICT, non-passive interaction is opt-in only. It doesn't mean this won't have any side effect on other maintainers, but if one maintainer wants non-passive interactions, then that maintainer probably needs to define what is supposed to be used with (or just embed the source in the tree and provide selftests). Cheers, Benjamin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-21 16:33 ` Benjamin Tissoires @ 2022-06-23 20:15 ` Jiri Kosina 2022-06-23 21:23 ` Alexei Starovoitov 0 siblings, 1 reply; 28+ messages in thread From: Jiri Kosina @ 2022-06-23 20:15 UTC (permalink / raw) To: Benjamin Tissoires; +Cc: Steven Rostedt, Hans de Goede, ksummit 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-23 20:15 ` Jiri Kosina @ 2022-06-23 21:23 ` Alexei Starovoitov 2022-06-23 21:36 ` Steven Rostedt 0 siblings, 1 reply; 28+ messages in thread From: Alexei Starovoitov @ 2022-06-23 21:23 UTC (permalink / raw) To: Jiri Kosina; +Cc: Benjamin Tissoires, Steven Rostedt, Hans de Goede, ksummit On Thu, Jun 23, 2022 at 1:15 PM Jiri Kosina <jikos@kernel.org> wrote: > > 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. Apples are similar to oranges in many ways. > 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. tracepoints exposed an api through cat-able and echo-able files that 'ubertrace' can use without any knowledge of the underlying kernel, without access to kernel sources, etc. Now please explain how bpf based tracing tools are similar? What exposed api do they use? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-23 21:23 ` Alexei Starovoitov @ 2022-06-23 21:36 ` Steven Rostedt 0 siblings, 0 replies; 28+ messages in thread From: Steven Rostedt @ 2022-06-23 21:36 UTC (permalink / raw) To: Alexei Starovoitov Cc: Jiri Kosina, Benjamin Tissoires, Hans de Goede, ksummit On Thu, 23 Jun 2022 14:23:51 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > tracepoints exposed an api through cat-able and echo-able files > that 'ubertrace' can use without any knowledge of the underlying kernel, > without access to kernel sources, etc. > Now please explain how bpf based tracing tools are similar? > What exposed api do they use? Question to you. Can eBPF provide information that normally is not available without the eBPF program? Could there be someone that creates a eBPF program based on internal information where that developer had to read the kernel source to implement. But then provide this program to other users that can now write programs based on that new information? Years and versions can go by, and the code that the eBPF program hasn't changed so this works for years, without the maintainer of the attached code even being aware of this use. Then one day that maintainer changes the code and this eBPF program breaks for the first time in years, and with that, it breaks all the user space applications that relied on this. I can see that change falling under the "broke user space" clause of the Linux kernel and reverted. ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <20220615174358.GA26358@lst.de>]
[parent not found: <CAO-hwJKqA07KX+6QtotCS8PtHFtk3DLQPJ3W8puaHOv7tOdi+Q@mail.gmail.com>]
[parent not found: <20220616114856.GA11127@lst.de>]
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF [not found] ` <20220616114856.GA11127@lst.de> @ 2022-06-16 12:14 ` Benjamin Tissoires 0 siblings, 0 replies; 28+ messages in thread From: Benjamin Tissoires @ 2022-06-16 12:14 UTC (permalink / raw) On Thu, Jun 16, 2022 at 1:49 PM Christoph Hellwig <hch@lst.de> wrote: > > On Wed, Jun 15, 2022 at 08:34:19PM +0200, Benjamin Tissoires wrote: > > Also, one of the things I'd like to have in kfuncs is to be able to > > restrict them to a set of tracepoints, not just "all tracing > > programs". > > Yes. > > > Because the thing I do not want is users hijacking the kfunc API I > > define in other use cases I haven't thought of, and this would prevent > > changes. > > Yes. And I also think the BTF_IDs for kfuncs need to become something > like EXPORT_SYMBOL_EPBF to be more explicit and greppable and need to > see the same process. That is in-tree users and no guarantee of stability > for out of tree users. Sounds interesting :) > > > And AFAICT, I consider everything eBPF I do in HID as ABI, and treat > > it as such, and document it from day one. > > Yikes. So you're adding a UDI-like stable driver ABI? > No, I mean I am carefully defining the eBPF api I am willing to export to user space, and will restrain myself from shuffling arguments every single release. The last change in the HID core protocol was 20 years old, so we roughly know what it does. It is not so much of a task to define what will be unlikely to change. Maybe a better way of putting it: "I consider *almost* everything eBPF I do in HID as *UAPI*, and treat it as such, and document it from day one." Cheers, Benjamin ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <CAO-hwJJmW_STS=nT22n4pcaZf9gz953K4o2vhgmq-ig4OzxOLg@mail.gmail.com>]
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF [not found] ` <CAO-hwJJmW_STS=nT22n4pcaZf9gz953K4o2vhgmq-ig4OzxOLg@mail.gmail.com> @ 2022-06-16 8:02 ` Jiri Kosina 2022-06-16 11:37 ` Linus Walleij 0 siblings, 1 reply; 28+ messages in thread From: Jiri Kosina @ 2022-06-16 8:02 UTC (permalink / raw) On Wed, 15 Jun 2022, Benjamin Tissoires wrote: > One point that was also raised in the various HID-BPF patch series is > that for "hardware enablement" like support, the eBPF programs would be > in-tree, and automatically loaded by the kernel itself. > > Alexei has some ideas on how to implement that, I had others, but the > hallway track discussions showed that everybody has a different idea on > the automatic mechanism, but it is a requirement and worth discussing :) > > Which means that in that case, eBPF would be a more convenient way for > users to fix their device, without having to rely on a full or partial > kernel recompilation. That definitely does solve one of the issues. It's basically following the model of perf, where the ABI must not be kept intact, because the user(s) of it are in-tree and released in lockstep with the ABI changes. > While working on eBPF, I came to realize how hidraw is bad in terms of > development model for userspace "drivers". As the original author of hidraw, I have to agree :) I didn't expect such an explosion of userspace drivers being dependent on it, it was primarily meant for debugging and tweaking. libusb is a similar example, I believe. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-16 8:02 ` Jiri Kosina @ 2022-06-16 11:37 ` Linus Walleij 2022-06-16 12:09 ` Benjamin Tissoires 0 siblings, 1 reply; 28+ messages in thread From: Linus Walleij @ 2022-06-16 11:37 UTC (permalink / raw) On Thu, Jun 16, 2022 at 10:02 AM Jiri Kosina <jikos@kernel.org> wrote: > On Wed, 15 Jun 2022, Benjamin Tissoires wrote: > > > One point that was also raised in the various HID-BPF patch series is > > that for "hardware enablement" like support, the eBPF programs would be > > in-tree, and automatically loaded by the kernel itself. > > > > Alexei has some ideas on how to implement that, I had others, but the > > hallway track discussions showed that everybody has a different idea on > > the automatic mechanism, but it is a requirement and worth discussing :) > > > > Which means that in that case, eBPF would be a more convenient way for > > users to fix their device, without having to rely on a full or partial > > kernel recompilation. Convenient for some definition of convenient. I might be biased in asking how much harder it is to set up a kernel compile, rebuild a module and run a few insmod/rmmod to find a quirk compared to setting up the eBPF compiler and figure out how to compile and push in such programs. I guess I could be convinced. > That definitely does solve one of the issues. It's basically following the > model of perf, where the ABI must not be kept intact, because the user(s) > of it are in-tree and released in lockstep with the ABI changes. I agree, I would actually go so far as to taint the kernel if programs that are not in-tree are used. That is fine for the goal here: users can create new eBPF snippets and debug them, but they can't ship them because then the kernel gets tainted, so they MUST be submitted upstream. Do you think we could do this? Pushing taint in the face of people who don't follow our established contribution process is essentially the big hammer we have to stop fragmentation. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-16 11:37 ` Linus Walleij @ 2022-06-16 12:09 ` Benjamin Tissoires 0 siblings, 0 replies; 28+ messages in thread From: Benjamin Tissoires @ 2022-06-16 12:09 UTC (permalink / raw) On Thu, Jun 16, 2022 at 1:38 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Thu, Jun 16, 2022 at 10:02 AM Jiri Kosina <jikos@kernel.org> wrote: > > On Wed, 15 Jun 2022, Benjamin Tissoires wrote: > > > > > One point that was also raised in the various HID-BPF patch series is > > > that for "hardware enablement" like support, the eBPF programs would be > > > in-tree, and automatically loaded by the kernel itself. > > > > > > Alexei has some ideas on how to implement that, I had others, but the > > > hallway track discussions showed that everybody has a different idea on > > > the automatic mechanism, but it is a requirement and worth discussing :) > > > > > > Which means that in that case, eBPF would be a more convenient way for > > > users to fix their device, without having to rely on a full or partial > > > kernel recompilation. > > Convenient for some definition of convenient. I might be biased in asking > how much harder it is to set up a kernel compile, rebuild a module > and run a few insmod/rmmod to find a quirk compared to setting up > the eBPF compiler and figure out how to compile and push in such > programs. > > I guess I could be convinced. The plan is to forward to the end user the sources, of course, but also the binary blob. The binary can be checked that it is doing the correct thing because it's not so much of a black box and we can easily check that it is the one built from the source. For extra check the maintainer can also sign the binary. And for the end user, it is thus: 1. trust your kernel maintainer (see above if you don't), and 2. drop the binary in the file system and forget. So no compilation involved :) > > > That definitely does solve one of the issues. It's basically following the > > model of perf, where the ABI must not be kept intact, because the user(s) > > of it are in-tree and released in lockstep with the ABI changes. > > I agree, I would actually go so far as to taint the kernel if programs that are > not in-tree are used. That is fine for the goal here: users can create new > eBPF snippets and debug them, but they can't ship them because then > the kernel gets tainted, so they MUST be submitted upstream. > > Do you think we could do this? Pushing taint in the face of people who > don't follow our established contribution process is essentially the big > hammer we have to stop fragmentation. I would like to have that too. The in-kernel eBPF binaries are using a different path to be loaded so I would assume this is OK to differentiate, but I'll leave it to Alexei to give a more definitive answer. Cheers, Benjamin ^ permalink raw reply [flat|nested] 28+ messages in thread
* [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF 2022-06-15 6:55 [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF Jiri Kosina 2022-06-15 8:05 ` Linus Walleij @ 2022-06-15 18:35 ` Luis Chamberlain 1 sibling, 0 replies; 28+ messages in thread From: Luis Chamberlain @ 2022-06-15 18:35 UTC (permalink / raw) On Wed, Jun 15, 2022 at 08:55:47AM +0200, Jiri Kosina wrote: > I feel like we are currently lacking a clear borderline, defining what is > still acceptable by the community to be implemented in terms of eBPF, and > what is over the line as it'd be causing big supportability and > maintainability concerns (see e.g. Christoph's concern to the HID eBPF > implementation implications [2]). > > So I'd like to propose a session where we'd ideally converge closer to > defining a borderline between acceptable and non-acceptable usecases for > eBPF in the kernel. Can't the equivalent of an LSM be used for these considerations? Luis ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2022-06-23 21:36 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-15 6:55 [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF Jiri Kosina 2022-06-15 8:05 ` Linus Walleij 2022-06-15 8:36 ` Jiri Kosina 2022-06-15 17:04 ` Jan Kara 2022-06-15 17:25 ` Jonathan Corbet [not found] ` <20220615174601.GX1790663@paulmck-ThinkPad-P17-Gen-1> 2022-06-15 18:25 ` Jiri Kosina 2022-06-16 16:26 ` Steven Rostedt 2022-06-16 16:38 ` James Bottomley 2022-06-16 16:51 ` Steven Rostedt 2022-06-16 18:25 ` James Bottomley 2022-06-16 19:08 ` Steven Rostedt 2022-06-17 7:53 ` Jiri Kosina 2022-06-17 8:24 ` Linus Walleij 2022-06-17 10:30 ` Jan Kara 2022-06-17 11:04 ` Benjamin Tissoires [not found] ` <dc6ca88d-d1ef-a1ab-dbef-e9338467271d@redhat.com> 2022-06-17 11:25 ` Benjamin Tissoires 2022-06-17 11:32 ` Hans de Goede 2022-06-20 13:13 ` Steven Rostedt 2022-06-21 15:05 ` Steven Rostedt 2022-06-21 16:33 ` Benjamin Tissoires 2022-06-23 20:15 ` Jiri Kosina 2022-06-23 21:23 ` Alexei Starovoitov 2022-06-23 21:36 ` Steven Rostedt [not found] ` <20220615174358.GA26358@lst.de> [not found] ` <CAO-hwJKqA07KX+6QtotCS8PtHFtk3DLQPJ3W8puaHOv7tOdi+Q@mail.gmail.com> [not found] ` <20220616114856.GA11127@lst.de> 2022-06-16 12:14 ` Benjamin Tissoires [not found] ` <CAO-hwJJmW_STS=nT22n4pcaZf9gz953K4o2vhgmq-ig4OzxOLg@mail.gmail.com> 2022-06-16 8:02 ` Jiri Kosina 2022-06-16 11:37 ` Linus Walleij 2022-06-16 12:09 ` Benjamin Tissoires 2022-06-15 18:35 ` Luis Chamberlain
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.