Re: [RFC PATCH] fs: binfmt_misc: introduce eBPF-based matching and interpreter selection

["Farid Zakaria" <farid.m.zakaria@gmail.com>]

On Wed Jul 8, 2026 at 9:47 AM PDT, Christian Brauner wrote:
> On 2026-07-08 11:14 +0200, Christian Brauner wrote:
>> On 2026-07-07 15:44 -0700, Farid Zakaria wrote:
>> > On Tue Jul 7, 2026 at 12:45 PM PDT, Christian Brauner wrote:
>> > > On 2026-07-07 13:34 +0200, Christian Brauner wrote:
>> > >> On 2026-07-06 09:47:53-07:00, Farid Zakaria wrote:
>> > >> > On Mon, Jul 6, 2026 at 9:01 AM Christian Brauner <brauner@kernel.org> wrote:
>> > >> > 
>> > >> > > Ignoring the blatant bpf abuse here I think this is quite workable. So
>> > >> > > this can be turned into an actual design and patch imho...
>> > >> > 
>> > >> > Glad to see you think this proposal is in the right direction.
>> > >> > Just for my edification, when you say "balatant bpf abuse", you mean
>> > >> > how it abuses the socket bpf type?
>> > >> > If so, do you have any guidance on a new type or should I just take a
>> > >> > stab at it.
>> > >
>> > > I drafted a POC for you that should be closer to how this should look
>> > > like with the bpf people in Cc. I'll let you lead from now on. I just
>> > > wanted to help you out and illustrate a more viable direction. Might be
>> > > that the bpf people want it done differentely. Let's see.
>> > 
>> > Cool. I just saw the POC.
>> > (I'm trying out aerc to view the patch series. I will also try b4, I've
>> > never set it up before)
>> > I will rework my qemu demo to use the struct_ops and go through my own
>> > testing to see it work.
>> > 
>> > That looks very similar to what I was researching with an LLM. I was
>> > just going over the idea of struct_ops bpf (a new concept to me) and
>> > using traditional bpftool load, a new bpf program type and kfuncs.
>> > 
>> > You put out a surprising amount of polished code -- thank you.
>> 
>> I would not call this polished and it also lacks any tests... I've not
>> given the locking much thought and maybe there's easy wins on the table
>> I haven't been considering.
>> 
>> > I would have had to lean on an LLM (heavily) and from the patches I've
>> > put up so far they still have quite the gap to cover in terms of polish.
>> 
>> This isn't my first bpf ride in both kernel and userspace.
>> 
>> > What does "take it from here" mean in practicality?
>> 
>> Bring it over the finish line so I can merge it into my tree. :)
>> If the bpf people have no comments or worries than we're done. If they
>> want changes I'd appreciate if you could make them and slap you
>> Co-developed-by onto the whole thing as necessary.
>> 
>> Also, please ensure that this works for all the cases you're
>> considering.
>
> I have another cleanup series for binfmt_misc btw. That code is quite
> old. There might be a few additional series coming out of this work that
> we base the bpf bits on.

Sounds good. I just saw the patch series.
My plan at the least by the weekend is to:
* apply your binfmt_misc cleanup series
  * I will try b4 with aerc. Here  is my config if anyone wants to crib it [1].
* apply your POC series for the bpf to validate
* make any changes if necessary or just add selftests if it works as is

[1]: https://github.com/fzakaria/nix-home/blob/aaee67c3a6d035d06a62cb75392657563de58f4a/users/fmzakari/aerc.nix