Re: [PATCH v1 1/4] bpf: Add netpoll kfuncs for sending UDP packets

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 12 May 2026 13:25:04 -0700 Alexei Starovoitov wrote:
> On Tue May 12, 2026 at 6:53 AM PDT, Jakub Kicinski wrote:
> >> No. Nothing to do with 'user space prog'.  
> >
> > I'm sorry, are you saying that the motivation in the cover letter is
> > not the motivation? It'd be great if someone could reveal the real
> > motivation then.  
> 
> AI makes commit logs sound very convincing, so I don't read them anymore
> to avoid bias. Only looking at the code.
> And what I see in this set is a facility for emergency notifications
> that is safe to use in any context.

True, but I hope a real use case does exist for this given it's posted?

> If people bolt crypto on top and make a toy prototype out of it
> it doesn't take away from usefulness of sending UDP packets out.
> 
> I want to use it out of bpf core to notify of things like divide by zero,
> arena fault, etc. Currently they are sent via bpf_stream, but
> user space has to be there to pick up from the stream.
> We cannot use printk, since it's not safe.

printk is unsafe but netconsole is safe?

> So netcons is the only option available today for 'bad things happen'
> notifications.
> Theoretically con->write_atomic() can be wrapped in such helper/kfunc
> that both bpf core and bpf progs can call.
> progs also need emergency notifications.
> Like sched-ext might detect something bad and notify.
> But at the end netconsole_write() is netpoll_send_udp(),
> so more natural and simpler to just use that.

This sounds very scary. I mean it sounds exacting and technically
challenging, but I really don't want this to hinge on netpoll.
netpoll is not a good solution to synchronization problems.

> > In kernel sockets are used broadly. I accept that it's more work
> > for you but it's also the correct way to go about this if you want 
> > to send traffic from BPF.  
> 
> proper sockets and full TCP/UDP back and forth is a different use case.
> Maybe it will work for Mahe/Liam. I don't know.
> I'm arguing that emergency UDP is necessary too.
> We can skip netpoll_send_udp() and let bpf core prepare skb
> earlier in a good context, then at div-by-0 time populate it
> with a message and call netpoll_send_skb().
> Looks like netcons, bridge, vlan are using it, so why not let
> bpf core use it too?

Those drivers are not really using it, they are just trying to pass thru
the skb to the lower dev. And I'd be surprised if most of that stuff
even works, don't think it has any users. Most people try to pipe
netcons to eth0.

> __netpoll_send_skb() is the main value here because
> it's all trylock based at every step.
> The div-by-0 notification using normal sockets would have to be
> done async and that's the main downside.
> We'd need to irq_work, then schedule_work and then send it via socket.
> Way too many steps to do in emergency. If sched-ext messed it up
> kthread may or may not wakeup.

I think you may be overly optimistic on the dependability of netpoll.
Rik has added support for serial scraping at Meta because netconsole 
misses a lot of crucial alerts. And I can confirm there's a bunch of
errors that appear in that dataset that are missed by netcons.

Then there are little nuggets like some generations of bnxt NICs
having to discard all Rx frames when netcons is trying to send
and Tx is full (bnxt_force_rx_discard()). netpoll is really meant
for very narrow use cases, please trust me, opening it up for broader
use is not going to end well.