Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2274670imm; Mon, 16 Jul 2018 05:25:58 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeOLRRm8PQk7IYeIwGj0zd/UZjiPboh94aS4WkZ98/BZyXAjFNDn+PMN/cD7xpZLDLo+UNH X-Received: by 2002:a17:902:d710:: with SMTP id w16-v6mr16503252ply.93.1531743958062; Mon, 16 Jul 2018 05:25:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531743958; cv=none; d=google.com; s=arc-20160816; b=sRzML3ZkhI7X4RPQ/jQrPom0Lwz2XEVvP8b4DhV2rDvDz8rCBGPfdtD54iBihpk3la Yr0adkop9b3kDe/IkibmIz34LC6NomFGOo+/ZEGP16Q3yIOr2+2/GYAgfB85wVWXtZuR vj6ICwdnhkYCgkRZL6bYRJa4pce7cVEwBdz5Ix1uavF6TxL18Fibl0LHhuuOQNJTslU5 C0a2xMs4n9fyu6rckdGyvK39G2+bKXih3XkhNBEOEVk4mkB8E8HkxAk+cNoRvCfl3MBp F06UvuES2fbC173mA6jGC0g5A7unG9yhyGZedz7xKUPBtll/NbPLRazHzm3EcYWh+1i6 8+2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=GQ0IXxCKgLrcSy07A8wf5fRCZP/CVtcdaoJ0Zv6N0yk=; b=YI2ECeVI/yXJ8uvCiO8ZlN4q/bAFvxgvRXrPya1QRLaH2WoR8qZKCYrQ9ilMCx8Uxr oUMOzv455d6q3wrZgZIt7OFHCKrNdTIqV6u8k0qGaril4Khczjc1qbb7T+KPPIUm3RKS Q1wRwK6XsNzmx/TsZQcmIh7CDuEm42p2nCNOqrNcdvqLjOLNCc9Of4N82owgqLTqJlda JcsA2G/mHxMBkm1IVn9QwY3fiE0fTUBCS7ZFfLkj8TQpfKnc5cYtTL0a0v5wChZbRDSO QDVRIbk0TMiTpHCDRkK5em/fONgTuL7ns4uaIXbrE/GsaNAGTJZ7P+Eih3mdi3ugarQ8 2stw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m86-v6si23399902pfj.48.2018.07.16.05.25.42; Mon, 16 Jul 2018 05:25:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730733AbeGPMvj (ORCPT + 99 others); Mon, 16 Jul 2018 08:51:39 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:35272 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728574AbeGPMvi (ORCPT ); Mon, 16 Jul 2018 08:51:38 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A353D401EF04; Mon, 16 Jul 2018 12:24:25 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-124.pek2.redhat.com [10.72.12.124]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E8E78111E40F; Mon, 16 Jul 2018 12:24:16 +0000 (UTC) Date: Mon, 16 Jul 2018 20:24:12 +0800 From: Dave Young To: James Morse Cc: AKASHI Takahiro , catalin.marinas@arm.com, will.deacon@arm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Eric W. Biederman" Subject: Re: [PATCH v11 03/15] powerpc, kexec_file: factor out memblock-based arch_kexec_walk_mem() Message-ID: <20180716122412.GA7160@dhcp-128-65.nay.redhat.com> References: <20180711074203.3019-1-takahiro.akashi@linaro.org> <20180711074203.3019-4-takahiro.akashi@linaro.org> <20180714015223.GA2745@dhcp-128-65.nay.redhat.com> <2a4ec965-5258-5835-3022-8f403a2f6bdd@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a4ec965-5258-5835-3022-8f403a2f6bdd@arm.com> User-Agent: Mutt/1.9.5 (2018-04-13) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 16 Jul 2018 12:24:25 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 16 Jul 2018 12:24:25 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'dyoung@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/16/18 at 12:04pm, James Morse wrote: > Hi Dave, > > On 14/07/18 02:52, Dave Young wrote: > > On 07/11/18 at 04:41pm, AKASHI Takahiro wrote: > >> Memblock list is another source for usable system memory layout. > >> So powerpc's arch_kexec_walk_mem() is moved to kexec_file.c so that > >> other memblock-based architectures, particularly arm64, can also utilise > >> it. A moved function is now renamed to kexec_walk_memblock() and merged > >> into the existing arch_kexec_walk_mem() for general use, either resource > >> list or memblock list. > >> > >> A consequent function will not work for kdump with memblock list, but > >> this will be fixed in the next patch. > > >> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > > >> @@ -513,6 +563,10 @@ static int locate_mem_hole_callback(struct resource *res, void *arg) > >> int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf, > >> int (*func)(struct resource *, void *)) > >> { > >> + if (IS_ENABLED(CONFIG_HAVE_MEMBLOCK) && > >> + !IS_ENABLED(CONFIG_ARCH_DISCARD_MEMBLOCK)) > >> + return kexec_walk_memblock(kbuf, func); > > > > AKASHI, I'm not sure if this works on all arches, for example I chekced > > the .config on my Nokia N900 kernel tree, there is HAVE_MEMBLOCK=y and > > no CONFIG_ARCH_DISCARD_MEMBLOCK, in 32bit arm code no arch_kexec_walk_mem() > By doesn't work you mean it's a change in behaviour? > I think this is fine because 32bit arm doesn't support KEXEC_FILE, (this file is > kexec_file specific right?). Ah, replied on a train, I forgot this is only for kexec_file, sorry about that. Please ignore the comment. But since we have a weak function arch_kexec_walk_mem, adding another condition branch within this weak function looks not good. Something like below would be better: int kexec_locate_mem_hole(struct kexec_buf *kbuf) { int ret; + if use memblock + ret = kexec_walk_memblock() + else ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback); return ret == 1 ? 0 : -EADDRNOTAVAIL; } > > It only affects architectures with MEMBLOCK and KEXEC_FILE: powerpc, s390 and > soon arm64. s390 keeps its behaviour because it provides arch_kexec_walk_mem(), > and powerpc's is copied in here as its generic 'memblock describes my memory' > stuff. The implementation would be the same on arm64, so we're doing this to > avoid duplicating otherwise generic arch code. I think 32bit arm should be able > to use this too if it gets KEXEC_FILE support. (32bit arms' KEXEC already > depends on MEMBLOCK). > > > Thanks, > > James Thanks Dave