From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751685AbbHBQ04 (ORCPT ); Sun, 2 Aug 2015 12:26:56 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:39598 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751478AbbHBQ0z (ORCPT ); Sun, 2 Aug 2015 12:26:55 -0400 X-Helo: d03dlp03.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org Date: Sun, 2 Aug 2015 09:26:49 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Dave Jones , Linux Kernel , Josh Triplett Subject: Re: unpinning an unpinned lock. (pidns/scheduler) Message-ID: <20150802162649.GA27280@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150731174353.GA25799@codemonkey.org.uk> <20150802153807.GA1572@codemonkey.org.uk> <20150802160301.GE25159@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150802160301.GE25159@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15080216-0017-0000-0000-00000CCAB89A Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: > > > [] dump_stack+0x4f/0x7b > > > [] warn_slowpath_common+0x8a/0xc0 > > > [] warn_slowpath_fmt+0x46/0x50 > > > [] lock_unpin_lock+0x109/0x110 > > > [] __schedule+0x39f/0xb30 > > > [] 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