From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 25 12:55:37 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 87FB5616; Sun, 25 Nov 2012 12:55:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 995E38FC12; Sun, 25 Nov 2012 12:55:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA18339; Sun, 25 Nov 2012 14:55:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TcbkE-000Kw8-KS; Sun, 25 Nov 2012 14:55:34 +0200 Message-ID: <50B21545.5060807@FreeBSD.org> Date: Sun, 25 Nov 2012 14:55:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI References: <50A5F12C.1050902@FreeBSD.org> <50A63D1D.9090500@FreeBSD.org> <50A65208.4050804@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 12:55:37 -0000 on 25/11/2012 14:29 Attilio Rao said the following: > I think the patch you propose makes such effects even worse, because > it disables interrupts in generic_stop_cpus(). > What I suggest to do, is the following: > - The CPU which wins the race for generic_stop_cpus also signals the > CPUs it is willing to stop on a global mask > - Another CPU entering generic_stop_cpus() and loosing the race, > checks the mask of cpus which might be stopped and stops itself if > necessary (ie. not yet done). We must be careful with races here, but > I'm confindent this can be done easily enough. I think that you either misunderstood my patch or I misunderstand your suggestion, because my patch does exactly what you wrote above. -- Andriy Gapon