lkml.org 
[lkml]   [2011]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2011-10-20 23:27    [W:0.099 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site