Sven Auhagen <Sven.Auhagen@xxxxxxxxxx> 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.
