Re: [PATCH bpf-next v2 1/3] bpf: add bpf_ksock_sendto() kfunc

[Mahe Tardy <mahe.tardy@gmail.com>]

On Wed, Oct 21, 2026 at 10:56:23AM -0700, Andrii Nakryiko wrote:
> On Tue, Oct 20, 2026 at 8:59 AM Mahe Tardy <mahe.tardy@gmail.com> wrote:
> >
> > The motivation is to plumb more of the socket API into ksock, thus
> > supporting sendto() in addition to send() which makes a lot of sense in
> > the context of UDP sockets which are the only type currently supported.
> > This is useful when ksock is used to reply to specific addresses or send
> > to multiple addresses.
> >
> > Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
> > ---
> >  net/core/bpf_ksock.c | 96 +++++++++++++++++++++++++++++++-------------
> >  1 file changed, 69 insertions(+), 27 deletions(-)
> >

[...]

> >
> > -       return ret;
> > +/**
> > + * bpf_ksock_sendto() - Send data through a BPF kernel socket to a remote address.
> > + * @ks:                The BPF kernel socket context. Must be an acquired reference.
> > + * @data:      Pointer to the data to send.
> > + * @data__sz:  Size of the data to send.
> > + * @addr__nullable: Pointer to an IPv4 or IPv6 socket address, or NULL to use
> > + *                the connected destination.
> > + * @addr__sz:  Size of the address union, ignored when the address is NULL.
> > + *
> > + * Sends data to the specified address, or to the connected destination when
> > + * the address is NULL, best-effort and nonblocking. This may sleep
> > + * (kernel_sendmsg), so it can only be called from sleepable BPF programs.
> > + *
> > + * Return: Number of bytes sent on success, negative errno on error.
> > + */
> > +__bpf_kfunc int bpf_ksock_sendto(struct bpf_ksock *ks, const void *data, u32 data__sz,
> 
> This would limit API to fixed-sized data only. Have you considered
> passing dynptr as a source of data, so you can send a wider variety of
> data? I don't have a strong opinion whether we should add a separate
> API or convert this one into dynptr, but I do think that having
> ability to work with variable-sized data is super useful and should be
> added early on.

Oh wow this is really cool that you send this now. I was working this
afternoon on trying to see if a ksock sendmsg() would make sense, but
with these static buffer limitations as arguments, it actually didn't.
I'm not familiar with dynptr so I didn't think about it, but after a
quick check it looks like it would be a good match with the ksock API!

As I understand, since bpf_ksock_send() is already part of 7.3, it's
best to not touch it, and having a simple send() available with a
fixed-size data might make sense.

But since bpf_ksock_sendto() was just merged, we could make it evolve to
use dynptr perhaps? How much time do we have for something which was
merged yesterday to be part of a release? Is it going to be send with
the 7.4 pull soon?

> 
> > +                                const union bpf_ksock_addr *addr__nullable,
> > +                                u32 addr__sz)
> > +{
> > +       return ksock_sendto(ks, data, data__sz, addr__nullable, addr__sz);
> >  }
> >
> >  __bpf_kfunc_end_defs();
> > @@ -255,6 +296,7 @@ BTF_KFUNCS_START(ksock_kfunc_btf_ids)
> >  BTF_ID_FLAGS(func, bpf_ksock_release, KF_RELEASE)
> >  BTF_ID_FLAGS(func, bpf_ksock_acquire, KF_ACQUIRE | KF_RCU | KF_RET_NULL)
> >  BTF_ID_FLAGS(func, bpf_ksock_send, KF_SLEEPABLE)
> > +BTF_ID_FLAGS(func, bpf_ksock_sendto, KF_SLEEPABLE)
> >  BTF_KFUNCS_END(ksock_kfunc_btf_ids)
> >
> >  #ifdef CONFIG_BPF_LSM
> > --
> > 2.43.0
> >