cvs commit: src/sys/kern kern_mutex.c

[Attilio Rao]

2007/6/5, John Baldwin <jhb at freebsd.org>:
> On Tuesday 05 June 2007 11:43:03 am Attilio Rao wrote:
> > 2007/6/5, Attilio Rao <attilio at freebsd.org>:
> > > 2007/6/5, Bruce Evans <brde at 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 :)).

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein