Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752524AbdCTCPJ (ORCPT ); Sun, 19 Mar 2017 22:15:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35502 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513AbdCTCPF (ORCPT ); Sun, 19 Mar 2017 22:15:05 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3A1C47F6C8 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=dyoung@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3A1C47F6C8 Date: Mon, 20 Mar 2017 10:14:12 +0800 From: Dave Young To: Matt Fleming Cc: Omar Sandoval , Ingo Molnar , linux-kernel@vger.kernel.org, kernel-team@fb.com, kexec@lists.infradead.org, linux-efi@vger.kernel.org Subject: Re: kexec regression since 4.9 caused by efi Message-ID: <20170320021412.GA3793@dhcp-128-65.nay.redhat.com> References: <20170308201616.GC8598@vader> <20170309063806.GB17257@dhcp-128-65.nay.redhat.com> <20170309095408.GA17883@vader> <20170313073748.GA6332@dhcp-128-65.nay.redhat.com> <20170316124132.GF6261@codeblueprint.co.uk> <20170317020951.GA3942@dhcp-128-65.nay.redhat.com> <20170317133232.GI6261@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170317133232.GI6261@codeblueprint.co.uk> User-Agent: Mutt/1.7.1 (2016-10-04) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 20 Mar 2017 02:14:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 985 Lines: 26 On 03/17/17 at 01:32pm, Matt Fleming wrote: > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > > > > Matt, I think it should be fine although I think the md type checking in > > efi_mem_desc_lookup() is causing confusion and not easy to understand.. > > Could you make that a separate patch if you think of improvements > there? Duplicate the lookup function is indeed a little ugly, will do it when I have a better idea, we can leave it as is since it works. > > > How about move the if chunk early like below because it seems no need > > to sanity check the addr + size any more if the md is still RUNTIME? > > My original version did as you suggest, but I changed it because we > *really* want to know if someone tries to reserve a range that spans > regions. That would be totally unexpected and a warning about a > potential bug/issue. Matt, I'm fine if you prefer to capture the range checking errors. Would you like me to post it or just you send it out? Thanks Dave