[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120316194436.GN24602@redhat.com>
Date: Fri, 16 Mar 2012 20:44:36 +0100
From: Andrea Arcangeli <aarcange@...hat.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
Hugh Dickins <hughd@...gle.com>
Subject: Re: [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@...ux.intel.com>
>
> Use lockdep_assert_held to check for locks instead of an opencoded
> variant.
>
> Cc: aarcange@...hat.com
> Signed-off-by: Andi Kleen <ak@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists