On 4/1/22 22:31, 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? Please take look at memcg_kmem_bypass() called from memcg_slab_pre_alloc_hook -> get_obj_cgroup_from_current By default memcg accounting does not work for any kernel threads. If required thread can use set_active_memcg() but at present it is not widely used. >> 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. Ok, I think we can skip accounting in such cases at the moment. I doubt it can be misused and consume significant piece of host memory. So I'm going to resend the patch w/o accounting in all .clone callbacks. >> 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? Thanks to Roman for the explanation in concurrent thread. Thank you, Vasily Averin
