mem_cgroup_from_task() calls task_subsys_state() calls
task_subsys_state_check(). task_subsys_state_check() will be happy if
rcu_read_lock is held.
I don't think that this will fail lockdep, because rcu_read_lock_held()
is true when calling mem_cgroup_from_task() within
I do not understand how making mem_cgroup_from_task() a macro will
change its behavior wrt. to lockdep assertion checking. I assume that
as a macro mem_cgroup_from_task() would still call task_subsys_state(),
which requires either:
a) rcu read lock held
b) task->alloc_lock held
c) cgroup lock held
It seems like a shame to need a lock to determine if current is in the
root cgroup. Especially given that as soon as
mem_cgroup_has_dirty_limit() returns, the task could be moved
in-to/out-of the root cgroup thereby invaliding the answer. So the
answer is just a sample that may be wrong. But I think you are correct.
We will need the rcu read lock in mem_cgroup_has_dirty_limit().
What are the cases where current->mm->owner->cgroups !=
I was hoping to avoid having add even more logic into
mem_cgroup_has_dirty_limit() to handle the case where current->mm is
Presumably the newly proposed vm_dirty_param(),
mem_cgroup_has_dirty_limit(), and mem_cgroup_page_stat() routines all
need to use the same logic. I assume they should all be consistently
using current->mm->owner or current.