On Wed, 21 Sept 2022 at 10:46, Hou Tao <houtao1@xxxxxxxxxx> wrote:
>
> Hi,
>
> On 9/11/2022 8:23 PM, Shmulik Ladkani wrote:
> > This allows kernel code dealing with dynptrs obtain dynptr's available
> > size and current (w. proper offset) data pointer.
> >
> > Signed-off-by: Shmulik Ladkani <shmulik.ladkani@xxxxxxxxx>
> SNIP
> > +
> > +static inline void *bpf_dynptr_get_data(struct bpf_dynptr_kern *ptr)
> > +{
> > + return ptr->data ? ptr->data + ptr->offset : NULL;
> > +}
> Have one dummy question here. Is ptr->data == NULL is possible ? According to
> the function prototype of bpf_dynptr_from_mem(), data can not be NULL. And IMO
> in order to simplify the usage of bpf_dynptr_kernel, we need to ensure ptr->data
> should be not NULL, else will need to add a NULL checking for every access of
> bpf_dynptr_kernel in kernel.
Yes, ptr->data can always be NULL. And I think at this point if you're
accepting dynptr from BPF programs, the ship has sailed on ensuring it
is always non-NULL (and honestly I don't know if there's a huge
advantage to it vs the amount of verifier work that would be needed to
enable this).
For an example, see how bpf_ringbuf_reserve_dynptr sets it to NULL on
error. Verifier still tracks it as valid initialized dynptr, but later
operations will simply fail or return without doing anything at
runtime.
