Re: unpinning an unpinned lock. (pidns/scheduler)

[Paul E. McKenney]

On Sun, Aug 02, 2015 at 06:03:01PM +0200, Peter Zijlstra wrote:
> On Sun, Aug 02, 2015 at 11:38:07AM -0400, Dave Jones wrote:
> > On Fri, Jul 31, 2015 at 01:43:53PM -0400, Dave Jones wrote:
> >  > Just found a machine with this on 4.2-rc4
> >  > 
> >  > WARNING: CPU: 0 PID: 11787 at kernel/locking/lockdep.c:3497 lock_unpin_lock+0x109/0x110()
> >  > unpinning an unpinned lock
> >  > CPU: 0 PID: 11787 Comm: kworker/0:1 Not tainted 4.2.0-rc4-think+ #5
> >  > Workqueue: events proc_cleanup_work
> >  >  0000000000000009 ffff8804f8983988 ffffffff9f7f5eed 0000000000000007
> >  >  ffff8804f89839d8 ffff8804f89839c8 ffffffff9f07b72a 00000000000000a8
> >  >  0000000000000070 ffff8805079d5c98 0000000000000092 0000000000000002
> >  > Call Trace:
> >  >  [<ffffffff9f7f5eed>] dump_stack+0x4f/0x7b
> >  >  [<ffffffff9f07b72a>] warn_slowpath_common+0x8a/0xc0
> >  >  [<ffffffff9f07b7a6>] warn_slowpath_fmt+0x46/0x50
> >  >  [<ffffffff9f0d0c59>] lock_unpin_lock+0x109/0x110
> >  >  [<ffffffff9f7f944f>] __schedule+0x39f/0xb30
> >  >  [<ffffffff9f7f9ca1>] schedule+0x41/0x90
> 
> >  > ---[ end trace e75342db87128aeb ]---
> > 
> > I'm hitting this a few times a day now, I'll see if I can narrow down
> > a reproducer next week.   Adding the RCU cabal to Cc.
> 
> Thanks, I got a report from Sasha as well, but so far I'm a bit
> stumped on how this can happen.
> 
> Clearly there's an imbalance in some unlikely scheduler path, but so far
> its eluding me :/

No enlightenment from an RCU perspective, either.

On the unlikely off-chance that it is related, I have been hitting an
infrequent silent hard hang that appears to have been introduced late
in the current -rc series.  My first attempt to bisect converged on
what appears to be an irrelevant commit, probably because one of my
"git bisect good" instances was more lucky (unlucky for me) than good.
Each bisect step takes about 36 hours of runtime, running 3 instances in
parallel for 12 hours, so after double-checking the bisection, I believe
my next step is to make another run at making it happen more often.
Only the TREE07 rcutorture test seems to be able to make this happen,
though of course it just might be lower probability in the other tests.

Anyway, more as I learn more!

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/