Andrii Nakryiko wrote: > On Mon, Apr 24, 2023 at 10:29 PM Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > > > On Mon, Apr 24, 2023 at 12:46 PM John Fastabend > > <john.fastabend@xxxxxxxxx> wrote: > > > > > > Joanne Koong wrote: > > > > Add a new kfunc > > > > > > > > int bpf_dynptr_adjust(struct bpf_dynptr_kern *ptr, u32 start, u32 end); > > > > > > > > which adjusts the dynptr to reflect the new [start, end) interval. > > > > In particular, it advances the offset of the dynptr by "start" bytes, > > > > and if end is less than the size of the dynptr, then this will trim the > > > > dynptr accordingly. > > > > > > > > Adjusting the dynptr interval may be useful in certain situations. > > > > For example, when hashing which takes in generic dynptrs, if the dynptr > > > > points to a struct but only a certain memory region inside the struct > > > > should be hashed, adjust can be used to narrow in on the > > > > specific region to hash. > > > > > > Would you want to prohibit creating an empty dynptr with [start, start)? > > > > I'm open to either :) I don't reallysee a use case for creating an > > empty dynptr, but I think the concept of an empty dynptr might be > > useful in general, so maybe we should let this be okay as well? > > Yes, there is no need to artificially enforce a non-empty range. We > already use pointers to zero-sized memory region in verifier (e.g., > Alexei's recent kfunc existence check changes). In general, empty > range is a valid range and we should strive to have that working > without assumptions on who and how would use that. As long as it's > conceptually safe, we should support it. Ack. Agree sounds good to me.
