Messages in this thread | | | Date | Sat, 2 Apr 2022 11:55:49 +0300 | From | Vasily Averin <> | Subject | Re: [PATCH nft] nft: memcg accounting for dynamically allocated objects |
| |
On 4/1/22 22:31, Florian Westphal wrote: > Vasily Averin <vasily.averin@linux.dev> 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
| |