[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <987664A83D2D224EAE907B061CE93D5301649A6EAC@orsmsx505.amr.corp.intel.com>
Date: Wed, 10 Nov 2010 09:50:37 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Ingo Molnar <mingo@...e.hu>, Borislav Petkov <bp@...en8.de>,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Huang, Ying" <ying.huang@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mchehab@...hat.com" <mchehab@...hat.com>,
Frédéric Weisbecker <fweisbec@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Arjan van de Ven <arjan@...radead.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: RE: [RFC/Requirements/Design] h/w error reporting
> We could even have some (small) statically enabled build-time
> buffer that could be enabled straight away before any allocators
> are enabled.
Agreed - in fact the error reporting paths will also want
some pre-allocated guaranteed space at all times. Allocating
memory from within an NMI or Machine Check handler would
cause too many problems.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists