From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [PATCH EDAC 07/13] edac: add support for raw error reports Date: Fri, 15 Feb 2013 17:02:57 +0100 Message-ID: <20130215160257.GK14387@pd.tnic> References: <20130215141330.GF14387@pd.tnic> <20130215132530.4f3b7dab@redhat.com> <20130215154123.GH14387@pd.tnic> <20130215134929.3909cfa2@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from mail.skyhub.de ([78.46.96.112]:35025 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752593Ab3BOQDJ (ORCPT ); Fri, 15 Feb 2013 11:03:09 -0500 Content-Disposition: inline In-Reply-To: <20130215134929.3909cfa2@redhat.com> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Mauro Carvalho Chehab Cc: linux-acpi@vger.kernel.org, Huang Ying , Tony Luck , Linux Edac Mailing List , Linux Kernel Mailing List On Fri, Feb 15, 2013 at 01:49:29PM -0200, Mauro Carvalho Chehab wrote: > Sure, but calling kmalloc while handling a memory error doesn't seem > a very good idea, IMHO. So, better to either use an already allocated > space (or the stack). Either that, or prealloc a buffer on EDAC initialization. You probably won't need more than one in 99% of the cases so if you keep it simple with a single static buffer for starters, that would probably be the cleanest solution. > Yes, I know, but, on the other hand, there's the additional cost of > copying almost all data into the structure. That's very easily paralelizable on out-of-order CPUs (I'd say, all of them which need to run EDAC, can do that :-)) so it wouldn't hurt. Also, you could allocate the struct in the callers and work directly with its members before sending it down to edac_raw_mc_handle_error() - that would probably simplify the code a bit more. > Ok, I'll keep this patch on my git. I'll likely fold it with the > previous one on the final patchset. Yep. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --