From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751889Ab1JPFLq (ORCPT ); Sun, 16 Oct 2011 01:11:46 -0400 Received: from mail-bw0-f46.google.com ([209.85.214.46]:35588 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347Ab1JPFLo (ORCPT ); Sun, 16 Oct 2011 01:11:44 -0400 Date: Sun, 16 Oct 2011 08:09:20 +0300 From: Sergey Senozhatsky To: David Rientjes Cc: Borislav Petkov , Tejun Heo , Tejun Heo , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: WARNING: at kernel/lockdep.c:690 __lock_acquire+0x168/0x164b() Message-ID: <20111016050920.GB3475@swordfish> References: <20111015201239.GA3475@swordfish> <20111015222324.GA16432@liondog.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (10/15/11 15:32), David Rientjes wrote: > > > I think this is a problem with lockdep itself, could you try reverting > > > f59de8992aa6 ("lockdep: Clear whole lockdep_map on initialization") if > > > this reliably happens everytime you reboot (lockdep will only emit this > > > once and then will suppress future warnings until the next boot)? > > > > > > I think the new memset() is inadvertently clearing the name for > > > double_unlock_balance(). > > > > Great, > > > > so I'm not the only one seeing the above: > > http://marc.info/?l=linux-kernel&m=131468805610527 > > > > Due to it being very hard to reproduce, we dismissed it then as a > > possible hw corruption. > > > > But yeah, it looks like I have triggered it on -rc9 too, just the > > other day. Oh, and I see -rc6 and -rc8 warnings in the logs too. Ok, > > correction, not that hard to trigger. > > > > Could you try to revert f59de8992aa6 ("lockdep: Clear whole lockdep_map on > initialization") with this patch and see if it helps? Thanks. Sure, I'd love to and will do, it's just I'm not sure I can easily reproduce it. > --- > diff --git a/kernel/lockdep.c b/kernel/lockdep.c > --- a/kernel/lockdep.c > +++ b/kernel/lockdep.c > @@ -2874,7 +2874,10 @@ static int mark_lock(struct task_struct *curr, struct held_lock *this, > void lockdep_init_map(struct lockdep_map *lock, const char *name, > struct lock_class_key *key, int subclass) > { > - memset(lock, 0, sizeof(*lock)); > + int i; > + > + for (i = 0; i < NR_LOCKDEP_CACHING_CLASSES; i++) > + lock->class_cache[i] = NULL; > > #ifdef CONFIG_LOCK_STAT > lock->cpu = raw_smp_processor_id(); >