On Thu, Nov 14, 2019 at 08:16:57PM +0100, Michal Hocko wrote:
On Wed 13-11-19 17:08:29, Roman Gushchin wrote:
On Wed, Nov 13, 2019 at 05:29:34PM +0100, Michal Koutný wrote:
Hi.
On Wed, Nov 06, 2019 at 02:51:30PM -0800, Roman Gushchin guro@fb.com wrote:
Let's fix it by switching from css_tryget_online() to css_tryget().
Is this a safe thing to do? The stack captures a kmem charge path, with css_tryget() it may happen it gets an offlined memcg and carry out charge into it. What happens when e.g. memcg_deactivate_kmem_caches is skipped as a consequence?
The thing here is that css_tryget_online() cannot pin the online state, so even if returned true, the cgroup can be offline at the return from the function. So if we rely somewhere on it, it's already broken.
Then what is the point of this function and what about all other users?
Generally speaking, it's better to reduce it's usage to the bare minimum.
If it doesn't have any sensible semantic then I would argue it should go altogether otherwise we are going to chase new users again and aagain?
That's the plan: to audit all use cases and get rid of it where it's possible.
The problem is caused by an exiting task which is associated with an offline memcg. We're iterating over and over in the do {} while (!css_tryget_online()) loop, but obviously the memcg won't become online and the exiting task won't be migrated to a live memcg.
As discussed in other replies, the task is not yet exiting. However, the access to memcg isn't through `current` but `mm->owner`, i.e. another task of a threadgroup may have got stuck in an offlined memcg (I don't have a good explanation for that though).
The trace however points to current->mm or current->active_memcg. Is it possible that we have a stale active_memcg?
It wouldn't cause a rcu stall.
Thanks!