[PATCH] hugetlb_cgroup: use lockdep_assert_held rather than spin_is_locked

[PATCH] hugetlb_cgroup: use lockdep_assert_held rather than spin_is_locked

[Michal Hocko]

spin_lock may be an empty struct for !SMP configurations and so
arch_spin_is_locked may return unconditional 0 and trigger the VM_BUG_ON
even when the lock is held.

Replace spin_is_locked by lockdep_assert_held. We will not BUG anymore
but it is questionable whether crashing makes a lot of sense in the
uncharge path. Uncharge happens after the last page reference was
released so nobody should touch the page and the function doesn't update
any shared state except for res counter which uses synchronization of
its own.

Signed-off-by: Michal Hocko <mhocko@suse.cz>
---
 mm/hugetlb_cgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 9aae6f47433f..9edf189a5ef3 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -217,7 +217,7 @@ void hugetlb_cgroup_uncharge_page(int idx, unsigned long nr_pages,
 
 	if (hugetlb_cgroup_disabled())
 		return;
-	VM_BUG_ON(!spin_is_locked(&hugetlb_lock));
+	lockdep_assert_held(&hugetlb_lock);
 	h_cg = hugetlb_cgroup_from_page(page);
 	if (unlikely(!h_cg))
 		return;
-- 
2.1.0.rc1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] hugetlb_cgroup: use lockdep_assert_held rather than spin_is_locked

[Aneesh Kumar K.V]

Michal Hocko <mhocko@suse.cz> writes:

> spin_lock may be an empty struct for !SMP configurations and so
> arch_spin_is_locked may return unconditional 0 and trigger the VM_BUG_ON
> even when the lock is held.
>
> Replace spin_is_locked by lockdep_assert_held. We will not BUG anymore
> but it is questionable whether crashing makes a lot of sense in the
> uncharge path. Uncharge happens after the last page reference was
> released so nobody should touch the page and the function doesn't update
> any shared state except for res counter which uses synchronization of
> its own.

We do update the hugepage's hugetlb cgroup details. But as you mentioned,
this should not be an issue because we are in hugepage free.

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
> ---
>  mm/hugetlb_cgroup.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
> index 9aae6f47433f..9edf189a5ef3 100644
> --- a/mm/hugetlb_cgroup.c
> +++ b/mm/hugetlb_cgroup.c
> @@ -217,7 +217,7 @@ void hugetlb_cgroup_uncharge_page(int idx, unsigned long nr_pages,
>
>  	if (hugetlb_cgroup_disabled())
>  		return;
> -	VM_BUG_ON(!spin_is_locked(&hugetlb_lock));
> +	lockdep_assert_held(&hugetlb_lock);
>  	h_cg = hugetlb_cgroup_from_page(page);
>  	if (unlikely(!h_cg))
>  		return;
> -- 
> 2.1.0.rc1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>