Re: [PATCH v9 bpf-next 3/5] bpf: Add skb dynptrs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 31, 2023 at 1:11 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Tue, Jan 31, 2023 at 12:48 PM Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
> > > > >
> > > > > p = bpf_dynptr_slice(dp, off, 16, buf);
> > > > > if (p == NULL) {
> > > > >    /* out of range */
> > > > > } else {
> > > > >    /* work with p directly */
> > > > > }
> > > > >
> > > > > /* if we wrote something to p and it was copied to buffer, write it back */
> > > > > if (p == buf) {
> > > > >     bpf_dynptr_write(dp, buf, 16);
> > > > > }
> > > > >
> > > > >
> > > > > We'll just need to teach verifier to make sure that buf is at least 16
> > > > > byte long.
> > > >
> > > > I'm confused what the benefit of passing in the buffer is. If it's to
> > > > avoid the uncloning, this will still need to happen if the user writes
> > > > back the data to the skb (which will be the majority of cases). If
> > > > it's to avoid uncloning if the user only reads the data of a writable
> > > > prog, then we could add logic in the verifier so that we don't pull
> > > > the data in this case; the uncloning might still happen regardless if
> > > > another part of the program does a direct write. If the benefit is to
> > > > avoid needing to pull the data, then can't the user just use
> > > > bpf_dynptr_read, which takes in a buffer?
> > >
> > > There is no unclone and there is no pull in xdp.
> > > The main idea of this semantics of bpf_dynptr_slice is to make it
> > > work the same way on skb and xdp for _read_ case.
> > > Writes are going to be different between skb and xdp anyway.
> > > In some rare cases the writes can be the same for skb and xdp
> > > with this bpf_dynptr_slice + bpf_dynptr_write logic,
> > > but that's a minor feature addition of the api.
> >
> > bpf_dynptr_read works the same way on skb and xdp. bpf_dynptr_read
> > takes in a buffer as well, so what is the added benefit of
> > bpf_dynptr_slice?
>
> That it doesn't copy most of the time.

Ohh I see, I missed that bpf_dynptr_slice also returns back a ptr.
This makes sense to me now, thanks for clarifying.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux