| Message ID | 47cbdb76178a112763a3766a03d8cc51842fcab0.1652876188.git.esyr@redhat.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | Fix kprobe_multi interface issues for 5.18 | expand |
On 5/18/22 5:22 AM, Eugene Syromiatnikov wrote: > Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels > for whatever reason, 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. If I understand correctly, the reason is due to in libbpf we have struct bpf_link_create_opts { size_t sz; /* size of this struct for forward/backward compatibility */ __u32 flags; union bpf_iter_link_info *iter_info; __u32 iter_info_len; __u32 target_btf_id; union { struct { __u64 bpf_cookie; } perf_event; struct { __u32 flags; __u32 cnt; const char **syms; const unsigned long *addrs; const __u64 *cookies; } kprobe_multi; }; size_t :0; }; Note that we have `const unsigned long *addrs;` If we have 32-bit user space application and 64bit kernel, and we will have userspace 32-bit pointers and kernel as 64bit pointers and current kernel doesn't handle 32-bit user pointer properly. Consider this may involve libbpf uapi change, maybe we should change "const unsigned long *addrs;" to "const __u64 *addrs;" considering we haven't freeze libbpf UAPI yet. Otherwise, we stick to current code with this patch, it will make it difficult to support 32-bit app with 64-bit kernel for kprobe_multi in the future due to uapi issues. WDYT? > > Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link") > Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com> > --- > kernel/trace/bpf_trace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > index 212faa4..2f83489 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c > @@ -2412,7 +2412,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr > int err; > > /* no support for 32bit archs yet */ > - if (sizeof(u64) != sizeof(void *)) > + if (sizeof(u64) != sizeof(void *) || in_compat_syscall()) > return -EOPNOTSUPP; > > if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI)
On Wed, May 18, 2022 at 09:55:05AM -0700, Yonghong Song wrote: > > > On 5/18/22 5:22 AM, Eugene Syromiatnikov wrote: > >Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels > >for whatever reason, 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. > > If I understand correctly, the reason is due to > in libbpf we have > struct bpf_link_create_opts { > size_t sz; /* size of this struct for forward/backward compatibility > */ > __u32 flags; > union bpf_iter_link_info *iter_info; > __u32 iter_info_len; > __u32 target_btf_id; > union { > struct { > __u64 bpf_cookie; > } perf_event; > struct { > __u32 flags; > __u32 cnt; > const char **syms; > const unsigned long *addrs; > const __u64 *cookies; > } kprobe_multi; > }; > size_t :0; > }; > > Note that we have `const unsigned long *addrs;` > > If we have 32-bit user space application and 64bit kernel, > and we will have userspace 32-bit pointers and kernel as > 64bit pointers and current kernel doesn't handle 32-bit > user pointer properly. > > Consider this may involve libbpf uapi change, maybe > we should change "const unsigned long *addrs;" to > "const __u64 *addrs;" considering we haven't freeze > libbpf UAPI yet. > > Otherwise, we stick to current code with this patch, > it will make it difficult to support 32-bit app with > 64-bit kernel for kprobe_multi in the future due to > uapi issues. > > WDYT? As 32 bit arches are "unsupported" currently, the change would be more a semantic one rather then practical; I don't mind having it here (basically, the tools/* part of [1]), though (assuming it is still possible to get it in 5.18). [1] https://lore.kernel.org/lkml/6ef675aeeea442fa8fc168cd1cb4e4e474f65a3f.1652772731.git.esyr@redhat.com/ > > > >Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link") > >Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com> > >--- > > kernel/trace/bpf_trace.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > >index 212faa4..2f83489 100644 > >--- a/kernel/trace/bpf_trace.c > >+++ b/kernel/trace/bpf_trace.c > >@@ -2412,7 +2412,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr > > int err; > > /* no support for 32bit archs yet */ > >- if (sizeof(u64) != sizeof(void *)) > >+ if (sizeof(u64) != sizeof(void *) || in_compat_syscall()) > > return -EOPNOTSUPP; > > if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI) >
On 5/18/22 1:03 PM, Eugene Syromiatnikov wrote: > On Wed, May 18, 2022 at 09:55:05AM -0700, Yonghong Song wrote: >> >> >> On 5/18/22 5:22 AM, Eugene Syromiatnikov wrote: >>> Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels >>> for whatever reason, 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. >> >> If I understand correctly, the reason is due to >> in libbpf we have >> struct bpf_link_create_opts { >> size_t sz; /* size of this struct for forward/backward compatibility >> */ >> __u32 flags; >> union bpf_iter_link_info *iter_info; >> __u32 iter_info_len; >> __u32 target_btf_id; >> union { >> struct { >> __u64 bpf_cookie; >> } perf_event; >> struct { >> __u32 flags; >> __u32 cnt; >> const char **syms; >> const unsigned long *addrs; >> const __u64 *cookies; >> } kprobe_multi; >> }; >> size_t :0; >> }; >> >> Note that we have `const unsigned long *addrs;` >> >> If we have 32-bit user space application and 64bit kernel, >> and we will have userspace 32-bit pointers and kernel as >> 64bit pointers and current kernel doesn't handle 32-bit >> user pointer properly. >> >> Consider this may involve libbpf uapi change, maybe >> we should change "const unsigned long *addrs;" to >> "const __u64 *addrs;" considering we haven't freeze >> libbpf UAPI yet. >> >> Otherwise, we stick to current code with this patch, >> it will make it difficult to support 32-bit app with >> 64-bit kernel for kprobe_multi in the future due to >> uapi issues. >> >> WDYT? > > As 32 bit arches are "unsupported" currently, the change would be more > a semantic one rather then practical; I don't mind having it here (basically, > the tools/* part of [1]), though (assuming it is still possible to get it > in 5.18). > > [1] https://lore.kernel.org/lkml/6ef675aeeea442fa8fc168cd1cb4e4e474f65a3f.1652772731.git.esyr@redhat.com/ I think for patch [1], we only need libbpf and selftest change, no kernel change is needed since we explicitly does not support 32bit kernel in the beginning of function bpf_kprobe_multi_link_attach(): /* no support for 32bit archs yet */ if (sizeof(u64) != sizeof(void *)) return -EOPNOTSUPP; and in kernel, address (pointer) size will be considered long (64bit) which is exactly the libbpf change did that. > >>> >>> Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link") >>> Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com> >>> --- >>> kernel/trace/bpf_trace.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c >>> index 212faa4..2f83489 100644 >>> --- a/kernel/trace/bpf_trace.c >>> +++ b/kernel/trace/bpf_trace.c >>> @@ -2412,7 +2412,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr >>> int err; >>> /* no support for 32bit archs yet */ >>> - if (sizeof(u64) != sizeof(void *)) >>> + if (sizeof(u64) != sizeof(void *) || in_compat_syscall()) >>> return -EOPNOTSUPP; >>> if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI) >> >
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index 212faa4..2f83489 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -2412,7 +2412,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr int err; /* no support for 32bit archs yet */ - if (sizeof(u64) != sizeof(void *)) + if (sizeof(u64) != sizeof(void *) || in_compat_syscall()) return -EOPNOTSUPP; if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI)
Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels for whatever reason, 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. Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link") Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com> --- kernel/trace/bpf_trace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)