On Fri, Apr 01, 2022 at 09:31:59PM +0200, Florian Westphal wrote: > Vasily Averin <vasily.averin@xxxxxxxxx> wrote: > > > Same problem as connlimit, can be called from packet path. > > > Basically all GFP_ATOMIC are suspicious. > > > > > > Not sure how to resolve this, similar mechanics in iptables world (e.g. > > > connlimit or SET target) don't use memcg accounting. > > > > > > Perhaps for now resend with only the GFP_KERNEL parts converted? > > > Those are safe. > > > > It is safe for packet path too, _ACCOUNT allocation will not be able to find memcg > > in case of "!in_task()" context. > > On the other hand any additional checks on such path will affect performance. > > I'm not sure this works with ksoftirqd serving network stack? > > > Could you please estimate how often is this code used in the case of nft vs packet path? > > It depends on user configuration. > Update from packet path is used for things like port knocking or other > dyanamic filter lists, or somehing like Limiting connections to x-per-address/subnet and so on. > > > If the opposite is the case, then I can add __GFP_ACCOUNT flag depending on in_task() check. > > But what task/memcg is used for the accounting in that case? Root memcg/no accounting, which is the same. There is a way to account for a specific memcg in such cases, it's used for bpf maps, for example. We save a pointer to the memcg which created the map and charge it for all allocations from a !in_task context. But the performance can be affected, so let's not do without regression tests and a serious need. Thanks!
