From: Shakeel Butt <shakeelb@xxxxxxxxxx> Date: Thu, 20 Feb 2020 17:46:04 -0800 > We are testing network memory accounting in our setup and noticed > inconsistent network memory usage and often unrelated cgroups network > usage correlates with testing workload. On further inspection, it > seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in > IRQ context specially for cgroup v1. > > mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in IRQ context > and kind of assumes that this can only happen from sk_clone_lock() > and the source sock object has already associated cgroup. However in > cgroup v1, where network memory accounting is opt-in, the source sock > can be unassociated with any cgroup and the new cloned sock can get > associated with unrelated interrupted cgroup. > > Cgroup v2 can also suffer if the source sock object was created by > process in the root cgroup or if sk_alloc() is called in IRQ context. > The fix is to just do nothing in interrupt. > > WARNING: Please note that about half of the TCP sockets are allocated > from the IRQ context, so, memory used by such sockets will not be > accouted by the memcg. Then if we do this then we have to have some kind of subsequent change to attach these sockets to the correct cgroup, right?
