Date: Tue, 5 Jun 2007 13:27:20 -0400 From: John Baldwin <jhb@freebsd.org> To: "Attilio Rao" <attilio@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, 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: <200706051327.21307.jhb@freebsd.org> In-Reply-To: <3bbf2fe10706051012x76381687g98e034ceb47b3f26@mail.gmail.com> References: <200706051420.l55EKEih018925@repoman.freebsd.org> <200706051230.21242.jhb@freebsd.org> <3bbf2fe10706051012x76381687g98e034ceb47b3f26@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 05 June 2007 01:12:01 pm Attilio Rao wrote:
> 2007/6/5, John Baldwin <jhb@freebsd.org>:
> > On Tuesday 05 June 2007 11:43:03 am 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?
> > >
> > > 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:
> > >
> > > td = curthread;
> > > if (td->td_critnest > 0 || td1->td_priority >= td->td_priority)
> > > return;
> > >
> > > thread_lock(td1);
> > > if (!TD_IS_RUNNING(td1)) {
> > > ...
> > >
> > > mi_switch(SW_INVOL, NULL);
> > > ...
> > > }
> > > thread_unlock(td1);
> > >
> > > Which is wrong beacause td1 is not curthread and really curthread
> > > should be locked too when context switching.
> > >
> > > 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.
> >
> > If this is the old #ifndef PREEMPTION manual preemption stuff, then just
> > remove it. I've been wanting to axe it for a while, rwlocks don't do the
> > manual preemption either, and if it is getting in the way it's best to
just
> > purge it.
>
> Yes.
> More specifically, I always thought that code would just force a
> PREEMPTION point in the mtx_unlock(), instead it just happens in the
> !PREEMPTION case... is this a bug?
> I don't see why doing something like that in the !PREEMPTION point
> (but it can be I'm missing something :)).
In the PREEMPTION case, the act of making the threads runnable will trigger a
preemption (or set td_owepreempt). The !PREEMPTION stuff is to make
mtx_unlock() preempt when PREEMPTION isn't enabled in the kernel.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706051327.21307.jhb>