From owner-freebsd-hackers@FreeBSD.ORG  Mon Oct 11 18:45:27 2010
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28])
	by hub.freebsd.org (Postfix) with ESMTP id 139B81065672;
	Mon, 11 Oct 2010 18:45:27 +0000 (UTC)
	(envelope-from jkim@FreeBSD.org)
From: Jung-uk Kim <jkim@FreeBSD.org>
To: freebsd-hackers@freebsd.org
Date: Mon, 11 Oct 2010 14:45:03 -0400
User-Agent: KMail/1.6.2
References: <4CAE092A.60905@freebsd.org> <201010111211.37993.jhb@freebsd.org>
In-Reply-To: <201010111211.37993.jhb@freebsd.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201010111445.14920.jkim@FreeBSD.org>
Cc: Matthew Fleming <mdf@freebsd.org>, Andriy Gapon <avg@freebsd.org>
Subject: Re: generic_stop_cpus: prevent parallel execution
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2010 18:45:27 -0000

On Monday 11 October 2010 12:11 pm, John Baldwin wrote:
> On Thursday, October 07, 2010 1:53:46 pm Andriy Gapon wrote:
> > Here is patch that applies the technique from panic() to
> > generic_stop_cpus() to prevent its parallel execution on multiple
> > CPUs:
> > http://people.freebsd.org/~avg/generic_stop_cpus.diff
> >
> > In theory this could lead to two CPUs stopping each other and
> > everyone else, and thus a total system halt.
> >
> > Also, in theory, we should have some smarter locking here,
> > because two (or more CPUs) could be stopping unrelated sets of
> > CPUs.  But in practice, it seems, this function is only used to
> > stop "all other" CPUs.  Unless I overlooked other usages, that
> > is.
> >
> > Additionally, I took this opportunity to make amd64-specific
> > suspend_cpus() function use generic_stop_cpus() instead of
> > rolling out essentially duplicate code.  I couldn't see any
> > reason no to consolidate, but perhaps I missed something.

When I wrote the code, generic_stop_cpus() didn't exist.  Now it makes 
sense, though.

> > Big thanks to Matthew and his employer for the idea and example.
>
> One note.  Use 'cpu_spinwait()' in the inner loop waiting for
> 'stopping_cpu' to change.

+1.

Jung-uk Kim