lkml.org 
[lkml]   [2012]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 06/11] huge-memory: Use lockdep_assert_held
Hi Andi,

On Fri, Mar 16, 2012 at 12:00:59PM -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> Use lockdep_assert_held to check for locks instead of an opencoded
> variant.
>
> Cc: aarcange@redhat.com
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
> mm/huge_memory.c | 4 ++--
> mm/swap.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 91d3efb..28669c6 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2083,7 +2083,7 @@ static void collect_mm_slot(struct mm_slot *mm_slot)
> {
> struct mm_struct *mm = mm_slot->mm;
>
> - VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(&khugepaged_mm_lock));
> + lockdep_assert_held(&khugepaged_mm_lock);

This check was intended to be a VM debug check, so getting enabled by
DEBUG_VM, not through lockdep. I mean I always have DEBUG_VM enabled
in all my kernels, but lockdep only enabled on my test system. So it's
not an opencoded variant strictly speaking.

My estimate is that what gets more tested is BUG_ON, second VM_BUG_ON,
third LOCKDEP. But hey, this code has been tested for a while so I'm
neutral and if you prefer the lockdep version it's up to you.

Thanks,
Andrea


\
 
 \ /
  Last update: 2012-03-16 20:47    [W:0.099 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site