memcg/sl[au]b: shrink dead caches

	cachep = memcg_params_to_cache(p);

	if (!atomic_read(&cachep->memcg_params->nr_pages))

	/*

	 * If we get down to 0 after shrink, we could delete right away.

	 * However, memcg_release_pages() already puts us back in the workqueue

	 * in that case. If we proceed deleting, we'll get a dangling

	 * reference, and removing the object from the workqueue in that case

	 * is unnecessary complication. We are not a fast path.

	 *

	 * Note that this case is fundamentally different from racing with

	 * shrink_slab(): if memcg_cgroup_destroy_cache() is called in

	 * kmem_cache_shrink, not only we would be reinserting a dead cache

	 * into the queue, but doing so from inside the worker racing to

	 * destroy it.

	 *

	 * So if we aren't down to zero, we'll just schedule a worker and try

	 * again

	 */

	if (atomic_read(&cachep->memcg_params->nr_pages) != 0) {

		kmem_cache_shrink(cachep);

		if (atomic_read(&cachep->memcg_params->nr_pages) == 0)

			return;

	} else

		kmem_cache_destroy(cachep);

}

	if (!cachep->memcg_params->dead)

		return;

	/*

	 * There are many ways in which we can get here.

	 *

	 * We can get to a memory-pressure situation while the delayed work is

	 * still pending to run. The vmscan shrinkers can then release all

	 * cache memory and get us to destruction. If this is the case, we'll

	 * be executed twice, which is a bug (the second time will execute over

	 * bogus data). In this case, cancelling the work should be fine.

	 *

	 * But we can also get here from the worker itself, if

	 * kmem_cache_shrink is enough to shake all the remaining objects and

	 * get the page count to 0. In this case, we'll deadlock if we try to

	 * cancel the work (the worker runs with an internal lock held, which

	 * is the same lock we would hold for cancel_work_sync().)

	 *

	 * Since we can't possibly know who got us here, just refrain from

	 * running if there is already work pending

	 */

	if (work_pending(&cachep->memcg_params->destroy))

		return;

	/*

	 * We have to defer the actual destroying to a workqueue, because

	 * we might currently be in a context that cannot sleep.

		 * set, so flip it down to guarantee we are in control.

		 */

		c->memcg_params->dead = false;

		cancel_delayed_work_sync(&c->memcg_params->destroy);

		cancel_work_sync(&c->memcg_params->destroy);

		kmem_cache_destroy(c);

	}

	mutex_unlock(&set_limit_mutex);