Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Aug 2004 15:08:22 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Alfred Perlstein <alfred@FreeBSD.org>
Cc:        Kris Kennaway <kris@obsecurity.org>
Subject:    Re: cvs commit: src/sys/i386/i386 pmap.c src/sys/kern subr_witness.c
Message-ID:  <200408091508.22530.jhb@FreeBSD.org>
In-Reply-To: <20040808053321.GD57908@elvis.mu.org>
References:  <200408042031.i74KVKUf039025@repoman.freebsd.org> <20040808042703.GA64746@xor.obsecurity.org> <20040808053321.GD57908@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 08 August 2004 01:33 am, Alfred Perlstein wrote:
> * Kris Kennaway <kris@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@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



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