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

[Arnd Bergmann]

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;

I still get 1368 bytes stack frame in one config (with KASAN_STACK)
here, compared to 392 with my patch. In another config without
KASAN, the mainline version has 1344, the rearranged xdp_test_data
has 1088 bytes and the dynamic allocation variant uses 200.

The one-line change is probably enough to stay off my radar since
it stays below the arbitrary warning limit I test with to find
regressions, but 1368 bytes is still a lot, so there is a good
chance someone else will hit this again.

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

Let me know which variant you prefer.

       Arnd