On Fri, Sep 9, 2022 at 10:28 PM Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > On Fri, Sep 9, 2022 at 8:46 AM Song Liu <song@xxxxxxxxxx> wrote: > > > > On Thu, Sep 8, 2022 at 1:07 AM Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > > > > > Add two new helper functions: bpf_dynptr_is_null and > > > bpf_dynptr_is_rdonly. > > > > > > bpf_dynptr_is_null returns true if the dynptr is null / invalid > > > (determined by whether ptr->data is NULL), else false if > > > the dynptr is a valid dynptr. > > > > > > bpf_dynptr_is_rdonly returns true if the dynptr is read-only, > > > else false if the dynptr is read-writable. > > > > Might be a dump question.. Can we just let the bpf program to > > access struct bpf_dynptr? Using a helper for this feel like an > > overkill. > > > > Thanks, > > Song > > > > Not a dumb question at all, this is an interesting idea :) Right now > the struct bpf_dynptr is opaque from the bpf program side but if we > were to expose it (it'd still be read-only in the program), the > program could directly get offset and whether it's null, but would > need to do some manipulation to determine the size (since the last few > bits of 'size' stores the dynptr type and rd-only) and rd-only. I see > the advantages of either approach - personally I think it's cleaner if > the struct is completely opaque from the program side but I don't feel > strongly about it. If the worry is the overhead of needing a helper > for each, maybe another idea is to conflate them into 1 general > bpf_dynptr_get_info helper that returns offset, size, is_null, and > rd-only status? While all the helpers are fast direct calls, I think they are still slower than simple memory accesses. It is probably a good idea to benchmark the difference. While we can inline the helper functions in the verifier, it is cleaner if we simply expose the data? Thanks, Song
