cvs commit: src/sys/i386/i386 pmap.c src/sys/kern subr_witness.c

[John Baldwin]

On Sunday 08 August 2004 01:33 am, Alfred Perlstein wrote:
> * Kris Kennaway <kris at obsecurity.org> [040807 21:28] wrote:
> > On Wed, Aug 04, 2004 at 04:34:03PM -0400, John Baldwin wrote:
> > > On Wednesday 04 August 2004 04:31 pm, John Baldwin wrote:
> > > > jhb         2004-08-04 20:31:19 UTC
> > > >
> > > >   FreeBSD src repository
> > > >
> > > >   Modified files:
> > > >     sys/i386/i386        pmap.c
> > > >     sys/kern             subr_witness.c
> > > >   Log:
> > > >   Remove a potential deadlock on i386 SMP by changing the lazypmap
> > > > ipi and spin-wait code to use the same spin mutex (smp_tlb_mtx) as
> > > > the TLB ipi and spin-wait code snippets so that you can't get into
> > > > the situation of one CPU doing a TLB shootdown to another CPU that is
> > > > doing a lazy pmap shootdown each of which are waiting on each other. 
> > > > With this change, only one of the CPUs would do an IPI and spin-wait
> > > > at a time.
> > >
> > > Both this patch and the previous I have tested locally and also sent
> > > out to current@ for testing.  However, I received zero feedback (not
> > > even useless feedback), so they may theoretically be risky.
> >
> > Isn't this the patch I tested for you and reported that it did not fix
> > the problem?
>
> Y'know there's some existing research on these sort of low level
> deadlocks, ie. how to do TLB shootdown without deadlock in:
>
> "UNIX Internals: The New Frontiers"

Yes, and the failsafe algorithm is to halt all CPUs, do the change, then 
unhalt the CPUs forcing each one to do a TLB shootdown when it unfreezes.  
Unfortuantely, this has a very negative performance impact as the book also 
details.  The current code was written by Peter who is not all that dumb, 
Alfred.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org