From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754559AbdA0Ise (ORCPT ); Fri, 27 Jan 2017 03:48:34 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33410 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754259AbdA0Irq (ORCPT ); Fri, 27 Jan 2017 03:47:46 -0500 Date: Fri, 27 Jan 2017 09:47:23 +0100 From: Ingo Molnar To: Wei Yang Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Resend PATCH] x86/e820: break the loop when the region is less then current region Message-ID: <20170127084723.GD25162@gmail.com> References: <20170127024724.38506-1-richard.weiyang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170127024724.38506-1-richard.weiyang@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Wei Yang wrote: > e820_all_mapped() iterates the e820 table to check whether a region is > mapped or not. Since the e820 table is sorted, when the region is less than > the current region, no need to continue the iteration. > > The patch breaks the loop accordingly. > > Signed-off-by: Wei Yang > --- > arch/x86/kernel/e820.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > index 90e8dde..f4fb197 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -86,10 +86,16 @@ int __init e820_all_mapped(u64 start, u64 end, unsigned type) > for (i = 0; i < e820->nr_map; i++) { > struct e820entry *ei = &e820->map[i]; > > + /* Since the e820 table is sorted, when the region is less > + * than the current region, break it. > + */ > + if (ei->addr >= end) > + break; Please have a look at the relevant sections in Documentation/CodingStyle. (And yes, this file violates it in a number of ways, but that's no reason to add to the mess.) But, more importantly, the reason I have not applied the patch before is that while it's true that the e820 map is _eventually_ sorted, have you made certain that all calls to e820_all_mapped() are done when the map is already sorted? Thanks, Ingo