[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150916105535.GD3816@twins.programming.kicks-ass.net>
Date: Wed, 16 Sep 2015 12:55:35 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Tim Spriggs <tspriggs@...le.com>, davej@...emonkey.org.uk,
sasha.levin@...cle.com, linux-kernel@...r.kernel.org
Subject: Re: unpinning an unpinned lock
On Tue, Sep 15, 2015 at 02:42:44PM -0700, Paul E. McKenney wrote:
> > All nodes report from: kernel/locking/lockdep.c:3497 lock_unpin_lock+0xed/0xf0()
>
> > [<ffffffff810a49dd>] lock_unpin_lock+0xed/0xf0
> > [<ffffffff810962f1>] pick_next_task_fair+0x51/0x220
> > [<ffffffff816b2c9c>] __schedule+0x12c/0x990
> > [<ffffffff816b367e>] schedule+0x3e/0x80
> > [<ffffffff810a49dd>] lock_unpin_lock+0xed/0xf0
> > [<ffffffff816b2f21>] __schedule+0x3b1/0x990
> > [<ffffffff816b367e>] schedule+0x3e/0x80
Right, Sasha was reporting these too, I've not been able to reproduce
and neither have I been able to make sense of the extra debug bits Sasha
generated :/
I've even completely reimplemented the feature from scratch and compared
to see if I missed something -- either I'm being very consistent with my
mistakes or something else is happening.
In any case, I'll have another go at tackling this, otherwise I'll have
to disable this warning for now.
Note that this lockdep 'feature' is pure annotation, no actual logic was
changed.
--
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