From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752933AbcC3KAr (ORCPT ); Wed, 30 Mar 2016 06:00:47 -0400 Received: from mail-ig0-f171.google.com ([209.85.213.171]:37157 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751776AbcC3KAq (ORCPT ); Wed, 30 Mar 2016 06:00:46 -0400 Date: Wed, 30 Mar 2016 17:59:54 +0800 From: Boqun Feng To: Peter Zijlstra Cc: Ingo Molnar , Alfredo Alvarez Fernandez , Linus Torvalds , Sedat Dilek , "Theodore Ts'o" , linux-fsdevel , LKML Subject: Re: [Linux-v4.6-rc1] ext4: WARNING: CPU: 2 PID: 2692 at kernel/locking/lockdep.c:2017 __lock_acquire+0x180e/0x2260 Message-ID: <20160330095954.GB14352@fixme-laptop.cn.ibm.com> References: <20160327204810.GW6356@twins.programming.kicks-ass.net> <20160329084701.GA9393@gmail.com> <20160330093659.GS3408@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <20160330093659.GS3408@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Peter, On Wed, Mar 30, 2016 at 11:36:59AM +0200, Peter Zijlstra wrote: > On Tue, Mar 29, 2016 at 10:47:02AM +0200, Ingo Molnar wrote: >=20 > > > You are right; this is lockdep running into a hash collision; which i= s a new=20 > > > DEBUG_LOCKDEP test. See 9e4e7554e755 ("locking/lockdep: Detect chain_= key=20 > > > collisions"). > >=20 > > I've Cc:-ed Alfredo Alvarez Fernandez who added that test. >=20 > OK, so while the code in check_no_collision() seems sensible, it relies > on borken bits. >=20 > The whole chain_hlocks and /proc/lockdep_chains stuff appears to have > been buggered from the start. >=20 > The below patch should fix this. >=20 > Furthermore, our hash function has definite room for improvement. >=20 > --- > include/linux/lockdep.h | 8 +++++--- > kernel/locking/lockdep.c | 30 ++++++++++++++++++++++++------ > kernel/locking/lockdep_proc.c | 2 ++ > 3 files changed, 31 insertions(+), 9 deletions(-) >=20 > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h > index d026b190c530..2568c120513b 100644 > --- a/include/linux/lockdep.h > +++ b/include/linux/lockdep.h > @@ -196,9 +196,11 @@ struct lock_list { > * We record lock dependency chains, so that we can cache them: > */ > struct lock_chain { > - u8 irq_context; > - u8 depth; > - u16 base; > + /* see BUILD_BUG_ON()s in lookup_chain_cache() */ > + unsigned int irq_context : 2, > + depth : 6, > + base : 24; > + /* 4 byte hole */ > struct hlist_node entry; > u64 chain_key; > }; > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 53ab2f85d77e..91a4b7780afb 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c [...] > @@ -2860,11 +2882,6 @@ static int separate_irq_context(struct task_struct= *curr, > { > unsigned int depth =3D curr->lockdep_depth; > =20 > - /* > - * Keep track of points where we cross into an interrupt context: > - */ > - hlock->irq_context =3D 2*(curr->hardirq_context ? 1 : 0) + > - curr->softirq_context; > if (depth) { > struct held_lock *prev_hlock; > =20 > @@ -3164,6 +3181,7 @@ static int __lock_acquire(struct lockdep_map *lock,= unsigned int subclass, > hlock->acquire_ip =3D ip; > hlock->instance =3D lock; > hlock->nest_lock =3D nest_lock; > + hlock->irq_context =3D 2*(!!curr->hardirq_context) + !!curr->softirq_co= ntext; > hlock->trylock =3D trylock; > hlock->read =3D read; > hlock->check =3D check; This is just for cleaning up, right? However ->hardirq_context and ->softirq_context only defined when CONFIG_TRACE_IRQFLAGS=3Dy. So we should use macro like current_hardirq_context() here? Or considering the two helpers introduced in my RFC: http://lkml.kernel.org/g/1455602265-16490-2-git-send-email-boqun.feng@gmail= =2Ecom if you don't think that overkills ;-) Regards, Boqun [...] --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJW+6OWAAoJEEl56MO1B/q4EVEH/jMxtAM8nO5NgANWhgN6w6dC b9ByYXx5aHGIBoxECN1hxXbTCj+qINfXxdHyH8D0Lv0GCdVa+CqKUSWnUkYaYcoz cos9rLtxWv/AufpH8Tils+ziYccAuA+BGakWRXOQvky0K7kNR0qG0up8c2zqGIV8 Vf+myTnccM88E8tFz+HKUUyMFueLnLp+sRigpQcxEkI9I3wN1j1RgwSTY6rD0bL9 r3ICQWqmub/D1z5c7xMDogEp7dFNllf2iAcV+CXdba7jUTzHhXSzrVrJPml0fKpG E9qRETDu4wS0t9wPpKDHqrL2Va4mZ38jlXHqC+wQEEhc/wz4vsALZRueZaffqic= =HNAr -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r--