Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Jun 2007 19:47:40 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Attilio Rao <attilio@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Bruce Evans <brde@optusnet.com.au>
Subject:   Re: cvs commit: src/sys/kern kern_mutex.c
Message-ID:  <20070605164740.GY2268@deviant.kiev.zoral.com.ua>
In-Reply-To: <3bbf2fe10706050843x5aaafaafy284e339791bcfe42@mail.gmail.com>
References:  <200706051420.l55EKEih018925@repoman.freebsd.org> <20070606003412.W35544@besplex.bde.org> <20070605150005.GW2268@deviant.kiev.zoral.com.ua> <20070605150521.GX2268@deviant.kiev.zoral.com.ua> <20070606011022.R35623@besplex.bde.org> <3bbf2fe10706050829o2d756a4cu22f98cf11c01f5e4@mail.gmail.com> <3bbf2fe10706050843x5aaafaafy284e339791bcfe42@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--3CF/MBslHFRhO8r/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 05, 2007 at 05:43:03PM +0200, Attilio Rao wrote:
> 2007/6/5, Attilio Rao <attilio@freebsd.org>:
> >2007/6/5, Bruce Evans <brde@optusnet.com.au>:
> >>
> >> I get a "spin lock held too long" panic during (an interrupt in?) acpi
> >> initialization on booting non-PREEMPTION SCHED_4BSD SMP.  Haven't tried
> >> other cases.
> >
> >Do you have a backtrace or any other debugging stuffs available?
>=20
> Mmm, I think I got the bug.
> basically, in kern_mutex.c::_mtx_unlock_sleep(), in the not-preemptive
> case what happens at some point is:
>=20
> td =3D curthread;
> if (td->td_critnest > 0 || td1->td_priority >=3D td->td_priority)
>         return;
>=20
> thread_lock(td1);
> if (!TD_IS_RUNNING(td1)) {
> ...
>=20
> mi_switch(SW_INVOL, NULL);
> ...
> }
> thread_unlock(td1);
>=20
> Which is wrong beacause td1 is not curthread and really curthread
> should be locked too when context switching.
>=20
> To a first look the idea is that td and td1 should be locked both, but
> I just want more time to look better at it.

With the following patch, I get the
	panic: mutex sched lock recursed at .../kern_synch.c:379
with backtrace
mi_switch
_mtx_unlock_sleep
_mtx_unlock_flags
vm_pagezero


diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c
index e0592a8..bf44229 100644
--- a/sys/kern/kern_mutex.c
+++ b/sys/kern/kern_mutex.c
@@ -670,7 +670,9 @@ _mtx_unlock_sleep(struct mtx *m, int opts, const char *=
file, int line)
 			    "_mtx_unlock_sleep: %p switching out lock=3D%p", m,
 			    (void *)m->mtx_lock);
=20
+		thread_lock(td);
 		mi_switch(SW_INVOL, NULL);
+		thread_unlock(td);
 		if (LOCK_LOG_TEST(&m->lock_object, opts))
 			CTR2(KTR_LOCK, "_mtx_unlock_sleep: %p resuming lock=3D%p",
 			    m, (void *)m->mtx_lock);

--3CF/MBslHFRhO8r/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFGZZOsC3+MBN1Mb4gRAo9QAJ0eIEXdW7L4iv2VPwPqgE91Gk659ACgjm+t
Rwu/Za9DgLmMx1OhIihjauE=
=G420
-----END PGP SIGNATURE-----

--3CF/MBslHFRhO8r/--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070605164740.GY2268>