Messages in this thread | | | Date | Thu, 20 Oct 2011 14:23:53 -0700 | From | Tejun Heo <> | Subject | Re: WARNING: at kernel/lockdep.c:690 __lock_acquire+0x168/0x164b() |
| |
Hello,
On Thu, Oct 20, 2011 at 02:17:29PM -0700, David Rientjes wrote: > On Thu, 20 Oct 2011, Sergey Senozhatsky wrote: > > > > > FWIW, > > > > > > > > the box has been running here with f59de8992aa6 reverted for a couple of > > > > days now and no sign of the warning. I'll keep watching it but it looks > > > > ok so far, so David, you could've nailed it. > > > > > > > > > > Hello, > > > Well, the same with me. My laptop has been running with reverted f59de8992aa6 without any > > > problems so far. Yet, I'm not sure I understand how memset() and loop could > > > produce different results. > > > > > > > Oh, well, nevermind I think I get it. > > > > Reverting opens https://bugzilla.kernel.org/show_bug.cgi?id=35532 again. > > > > I don't know what that is since bugzilla.kernel.org is down :) The > problem is that the memset(), in addition to all the other fields in > lockdep_map, clears the "name" field, which is what the scheduler uses > via lock_set_sublcass() to prevent this lockdep warning. My initial > speculation seems to be confirmed since either you or Borislav have been > able to reproduce the warning since removing the memset(). > > Tejun, would you like to revert f59de8992aa6 ("lockdep: Clear whole > lockdep_map on initialization") since it fixes this lockdep warning?
Hmmm... the issue was that kmemcheck noticed that memory regions in lockdep_map are accessed before being set to any value. I'm feeling dim as usual and don't understand what's going on here. The function looks like the following.
void lockdep_init_map(struct lockdep_map *lock, const char *name, struct lock_class_key *key, int subclass) { memset(lock, 0, sizeof(*lock));
#ifdef CONFIG_LOCK_STAT lock->cpu = raw_smp_processor_id(); #endif if (DEBUG_LOCKS_WARN_ON(!name)) { lock->name = "NULL"; return; }
lock->name = name;
So, according to this thread, the problem is that the memset() clears lock->name field, right? But how can that be a problem? lock->name is always set to either "NULL" or @name. Why would clearing it before setting make any difference? What am I missing?
Thanks.
-- tejun
| |