Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753824AbZFQEE7 (ORCPT ); Wed, 17 Jun 2009 00:04:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750754AbZFQEEv (ORCPT ); Wed, 17 Jun 2009 00:04:51 -0400 Received: from terminus.zytor.com ([198.137.202.10]:35845 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750712AbZFQEEu (ORCPT ); Wed, 17 Jun 2009 00:04:50 -0400 Message-ID: <4A386B14.8030702@zytor.com> Date: Tue, 16 Jun 2009 21:03:32 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Huang Ying CC: Cliff Wickman , "linux-kernel@vger.kernel.org" , "mingo@elte.hu" , "yinghai@kernel.org" Subject: Re: [PATCH] x86: efi/e820 table merge fix References: <1245201005.11965.4.camel@yhuang-dev.sh.intel.com> <4A384914.1090900@zytor.com> <1245203099.11965.7.camel@yhuang-dev.sh.intel.com> In-Reply-To: <1245203099.11965.7.camel@yhuang-dev.sh.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1902 Lines: 47 Huang Ying wrote: >>> Why does BIOS mark memory region without EFI_MEMORY_WB as these types? >>> Any example? >>> >> Probably not, but if it does, it's broken, and the memory should be >> ignored. The original code had the EFI_MEMORY_WB check already, so it >> seems prudent to keep it. > > Maybe we need a real life example for that "fix". And attribute that to > the vendor in comments. > > Best Regards, > Huang Ying I think you're reading the patch backwards. Before the patch, the EFI code didn't look at the type *AT ALL*, it only looked at the EFI_MEMORY_WB attribute. This broke for SGI when they were -- correctly -- reserving real memory (and hence still EFI_MEMORY_WB) with the type set to EFI_RESERVED_TYPE. This is correct behavior, but the old code saw that it was EFI_MEMORY_WB and therefore considered it usable RAM. This is obviously broken. Now why, you're asking, do we still look at md->attribute at all? That's where caution dictates that it is prudent to diverge from the previous behavior, but it is not *this* patch that should be the source of that question, but from the author of the existing code, which appears to be Paul Jackson of SGI. Unfortunately, his email now bounces and noone has that information. If you think about it, though, we don't want to consider it as usable RAM if it isn't EFI_MEMORY_WB, and it would in fact be a bug (or workaround for a broken system) to ignore it. In fact, we go through great pains elsewhere in the kernel to remove memory which isn't WB from the usable pool. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/