Re: Cannot allocate memory delete table inet filter

[Florian Westphal <fw@strlen.de>]

Sven Auhagen <Sven.Auhagen@belden.com> wrote:
> we do see on occasions that we get the following error message, more so on x86 systems than on arm64:
> 
> Error: Could not process rule: Cannot allocate memory delete table inet filter
> 
> It is not a consistent error and does not happen all the time.
> We are on Kernel 6.6.80, seems to me like we have something along the lines of the nf_tables: allow clone callbacks to sleep problem using GFP_ATOMIC.

Yes, set element deletion (flushing) requires atomic (non-sleepable)
allocations.

> Do you have any idea what I can try out/look at?

Do you have large sets? (I suspect yes).

As for a solution, I can see two:
1). Leverage what nft_set_pipapo.c is doing and extend
    this for all sets that could use the same solution.
    The .walk callback for pipapo doesn't need/use rcu read locks,
    and could use sleepable allocations.
    all set types except rhashtable could follow this.

    Then, we'd just need a way for the generic flush code to
    see that the walk callback can sleep (e.g. by annotation in
    set_ops).

    Upside: Clean and straightforward solution.
    Downside: won't work for rhashtable which runs under
    rcu read lock protection.
 2). Preallocate transaction elements before calling .walk
     in nft_set_flush(), based on set->nelems.

2) is a bit more (w)hacky but it would work for all set types.
And I could be wrong and the alloc problem isn't related to
nft_set_flush.