On 30/03/2021 20:21, Sasha Levin wrote:
> commit 8d92db5c04d10381f4db70ed99b1b576f5db18a7 upstream.
>>
>> This is an adaptation of parts from above commit to kernel 5.4.
>
> This is very different from the upstream commit, let's not annotate it
> as that commit.
>
No problem.
>>
>> To generally fix the issue, upstream includes new BPF helpers:
>> bpf_probe_read_{user,kernel}_str(). For details on them, see
>> commit 6ae08ae3dea2 ("bpf: Add probe_read_{user, kernel} and probe_read_{user, kernel}_str helpers")
>
> What stops us from taking that API back to 5.4? I took a look at the
> dependencies and they don't look too scary.
>
> Can we try that route instead? We really don't want to diverge from
> upstream that much.
>
probe_read_{user,kernel}* functions themselves seem simple enough.
Importing them in a forward-compliant way to 5.4 would require either
adding an unused entry in bpf.h's __BPF_FUNC_MAPPER or also pulling
skb_output bpf helper functions into 5.4. To me, it seems like too
much of a UAPI change to go into a stable release.
Another option would be to import more code to make it somewhat closer
to upstream implementation without changing UAPI. As in v5.8, I could
internally map these helpers to probe_read_compat* functions, which
will in turn call probe_read_{user,kernel}*_common functions.
Func names might seem weird out of context, but it will be closer.
Implementation will still defer, e.g. to avoid warnings on platforms
without ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
Does that sound like a reasonable solution?
--
Thanks,
Tsahi
