On Mon, 8 Jun 2020 11:36:33 -0700 Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > On Mon, Jun 8, 2020 at 9:51 AM Jesper Dangaard Brouer <brouer@xxxxxxxxxx> wrote: > > > > This patch change BPF syscall to avoid returning file descriptor value zero. > > > > As mentioned in cover letter, it is very impractical when extending kABI > > that the file-descriptor value 'zero' is valid, as this requires new fields > > must be initialised as minus-1. First step is to change the kernel such that > > BPF-syscall simply doesn't return value zero as a FD number. > > > > This patch achieves this by similar code to anon_inode_getfd(), with the > > exception of getting unused FD starting from 1. The kernel already supports > > starting from a specific FD value, as this is used by f_dupfd(). It seems > > simpler to replicate part of anon_inode_getfd() code and use this start from > > offset feature, instead of using f_dupfd() handling afterwards. > > Wouldn't it be better to just handle that on libbpf side? That way it > works on all kernels and doesn't require this duplication of logic > inside kernel? IMHO this is needed on the kernel side, to pair it with the API change. I don't see how doing this in libbpf can cover all cases. First of all, some users might not be using libbpf. Second, a userspace application could be using an older version of libbpf on a newer kernel. (Notice this is not only due to older distros, but also because projects using git submodule libbpf will freeze at some point in time that worked). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
