Hi Greg,
Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> On Thu, Jan 09, 2025 at 01:43:49PM -0800, Blaise Boscaccy wrote:
>> The new LOAD_FD subcommand keys off of a sysfs entry file descriptor
>> and a file descriptor pointing to a raw elf object file.
>
> A sysfs file descriptor? That feels very odd and is not how sysfs
> should be used, as it's only for text files and binary pass-through
> stuff.
>
Yeah, libbpf has a feature where it can load multiple independent
ebpf programs from a single object file. It parses the whole object file
and then for each program, calls BPF_PROG_LOAD. I was trying to mimic that
flow here, by having a single call to BPF_LOAD_FD and allowing
userspace to repeatedly call BPF_PROG_LOAD as needed referencing that
result.
bpffs would probably be a more appropriate choice for this. The purpose
of the PoC was mostly to test whether or not kernel relocs where even doable
and if there was any support for it upstream. The interface could
definitely use some polishing.
I'm also not sure how pervasive that use case is in the wild and if it is
more of a premature optimization here than anything. Alternatively, it
may be acceptable to combine BPF_LOAD_FD and BPF_PROG_LOAD into a single
operation and reparse/relocate for each discrete program load and then
remove all this.
>> +static void bpf_loader_show_fdinfo(struct seq_file *m, struct file *filp)
>> +{
>> + int i;
>> + struct bpf_obj *obj = filp->private_data;
>> +
>> + for (i = 0; i < obj->nr_programs; i++)
>> + seq_printf(m, "program: %s\n", obj->progs[i].name);
>
> So what file is printing this out in sysfs?
There are two file descriptors passed into BPF_LOAD_FD, this uses the
first one (bpffs_fd).
> Where is the
> Documentation/ABI/ entry for it?
>
That's still a TODO and an oversight on my part.
> confused,
>
> greg k-h
Thanks for the feedback.
-blaise
