On Tue, May 10, 2022 at 11:42 AM Eugene Syromiatnikov <esyr@xxxxxxxxxx> wrote: > > On Tue, May 10, 2022 at 11:10:35AM -0700, Alexei Starovoitov wrote: > > On Fri, May 6, 2022 at 7:22 AM Eugene Syromiatnikov <esyr@xxxxxxxxxx> wrote: > > > > > > Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels > > > for whatever reason, > > > > Jiri, > > why did you add this restriction? > > > > > having it enabled for compat processes on 64-bit > > > kernels makes even less sense due to discrepances in the type sizes > > > that it does not handle. > > > > I don't follow this logic. > > bpf progs are always 64-bit. Even when user space is 32-bit. > > Jiri's check is for the kernel. > > The interface as defined (and implemented in libbpf) expects arrays of userspace > pointers to be passed (for example, syms points to an array of userspace > pointers—character strings; same goes for addrs, but with generic userspace > pointers) without regard to possible difference in the pointer size in case > of compat userspace. I see. So kprobe_multi.syms and kprobe_multi.addrs will be 'long' and 32-bit user space will have an issue with the 64-bit kernel. Let's fix it properly. We can remove sizeof(u64) != sizeof(void *) and keep libbpf as-is by keeping syms and addrs 'long' in uapi. As far as I can see 32-bit user space on a 32-bit kernel should work with existing code. in_compat_syscall() can be used to extend addrs/syms.
