Re: [PATCH] bpf: test_run: reduce kernel stack usage

[Alexei Starovoitov]

On Fri, May 15, 2026 at 8:16 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Fri, May 15, 2026, at 16:47, Alexei Starovoitov wrote:
> > On Fri, May 15, 2026 at 4:31 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> >
> > 1k?
> > pahole -C xdp_test_data
> > /* size: 192, cachelines: 3, members: 9 */
> > /* sum members: 120, holes: 1, sum holes: 56 */
> > /* padding: 16 */
> > /* paddings: 1, sum paddings: 36 */
> >
> > what s390 doing to make it huge?
>
> I think it's a combination of cacheline alignment (256 byte
> lines) that leads to padding before 'rxq' and at the end of
> xdp_test_data, as well as CONFIG_KASAN_STACK that increases
> the stack usage further.
>
> > Probably better to rearrange the field and fix the root cause.
>
> It looks like this change reduces the stack usage by 256
> bytes, and keeps it under the warning limit for all the
> configurations I was testing:
>
> --- a/net/bpf/test_run.c
> +++ b/net/bpf/test_run.c
> @@ -98,8 +98,8 @@ struct xdp_page_head {
>  };
>
>  struct xdp_test_data {
> -       struct xdp_buff *orig_ctx;
>         struct xdp_rxq_info rxq;
> +       struct xdp_buff *orig_ctx;
>         struct net_device *dev;
>         struct page_pool *pp;
>         struct xdp_frame **frames;

yeah. this is much better.

> Another alternative would be to allocate xdp_test_data statically
> instead of on the stack.

iirc test_run can execute it in parallel, so static won't work.