Re: [PATCH v2 bpf-next 2/5] bpf: udp: Propagate ENOMEM up from bpf_iter_udp_batch

[Jordan Rife <jordan@jrife.io>]

> I am concerned having higher unnecessary failure chance (although unlikely)
> for the current use cases that do not care for a sk repeated or not. For
> example, the bpf prog has checked the sk conditions
> (address/port/tcp-cc...etc) before doing setsockopt or doing
> bpf_sock_destory.
> 
> I may have over-thought here. ok to bite the bullet on GFP_ATOMIC but I will
> be more comfortable if it can retry a few times on the "resized == true"
> case first with GFP_USER before finally resort to GFP_ATOMIC. or may be
> another way around GFP_ATOMIC fist and falls back to GFP_USER. Thoughts?

Sure, this sounds like a good balance. I'm leaning towards falling back
to GFP_ATOMIC if trying GFP_USER first hits the resized == true case,
since then most of the time you wouldn't have to hold onto the spin lock
any longer we already are. Maybe try with GFP_USER two times before
falling back? I can add a new patch to then next version of this series
with a PoC to review.

> 
> For tracking the maximum list length, not sure how much it will help
> considering it may still change, so it still needs to handle the
> resize+realloc situation regardless.

Yeah, thinking about this more today it's not very helpful. Also,
tracking the current longest list length gets a bit messy.

-Jordan