Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754150Ab1FOIvj (ORCPT ); Wed, 15 Jun 2011 04:51:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1281 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753408Ab1FOIvi (ORCPT ); Wed, 15 Jun 2011 04:51:38 -0400 Message-ID: <4DF8727F.3050507@redhat.com> Date: Wed, 15 Jun 2011 11:51:11 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: "Luck, Tony" CC: Borislav Petkov , Ingo Molnar , "linux-kernel@vger.kernel.org" , "Huang, Ying" , Hidetoshi Seto Subject: Re: [PATCH 08/10] NOTIFIER: Take over TIF_MCE_NOTIFY and implement task return notifier References: <4DF5C36A.1040707@redhat.com> <20110613095521.GA26316@aftab> <4DF5F729.4060609@redhat.com> <20110613124003.GA27918@aftab> <4DF606C9.90308@redhat.com> <20110613151208.GA29045@aftab> <4DF63B7A.1030805@redhat.com> <4DF748C2.10009@redhat.com> <20110614133323.GB2830@aftab> <4DF76586.1090308@redhat.com> <987664A83D2D224EAE907B061CE93D5301E7280DF7@orsmsx505.amr.corp.intel.com> In-Reply-To: <987664A83D2D224EAE907B061CE93D5301E7280DF7@orsmsx505.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1254 Lines: 27 On 06/14/2011 08:13 PM, Luck, Tony wrote: > >Since we can't have nested #MC (due to the IST mechanism resetting %rsp > >and clobbering the previous invocation's stack), we have to clear MCIP > >outside the #MC handler. And that means irq_work_queue() > > > >(note that this changes the behaviour from memory corruption to shutdown > >state; both suck, but one more than the other). > > Hmm. We currently clear MCIP inside the handler (at the very end, but > still inside). Deferring clearing would make sense - but we'd have to > be sure to do so a.s.a.p on all processors. It also would change how > we look at the possibility of a process being able to run and re-execute > an instruction that causes a machine check. If we defer clearing MCIP > this won't just be annoying, it will be fatal (if any cpu hasn't yet > got to the work queue to clear MCIP). Clearly, the work queue (or thread) has to be real-time at the highest priority. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/