linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	James Morse <james.morse@arm.com>,
	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" <ebiederm@xmission.com>
Subject: Re: [PATCH v11 03/15] powerpc, kexec_file: factor out memblock-based arch_kexec_walk_mem()
Date: Tue, 17 Jul 2018 15:49:23 +0800	[thread overview]
Message-ID: <20180717074923.GA8591@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <20180717053104.GB11258@linaro.org>

Hi AKASHI,
On 07/17/18 at 02:31pm, AKASHI Takahiro wrote:
> Hi Dave,
> 
> On Mon, Jul 16, 2018 at 08:24:12PM +0800, Dave Young wrote:
> > 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:
> 
> I see your concern here, but
> 
> 
> > 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;
> > }
> 
> what if yet another architecture comes to kexec_file and wanna
> take a third approach? How can it override those functions?
> Depending on kernel configuration, it might re-define either
> kexec_walk_memblock() or arch_kexec_walk_mem(). It sounds weird to me.

I also feel this weird, but it is slightly better because currently no
user need another overriding requirement, and I feel it is not expected to have in
the future for the memblock use.

Rethinking about this issue, we can just remove the weak function and
just use general function.

Currently with your patch applied only s390 use arch_kexec_walk_mem like
below:
/*
 * The kernel is loaded to a fixed location. Turn off kexec_locate_mem_hole
 * and provide kbuf->mem by hand.
 */
int arch_kexec_walk_mem(struct kexec_buf *kbuf,
                        int (*func)(struct resource *, void *))
{
        return 1;
}

AFAIK, all other users initialize kbuf->mem as NULL, so we can check
kbuf->mem in int kexec_locate_mem_hole:

if (kbuf->mem)
	return 0;

if use memblock
	kexec_walk_memblock
else
	kexec_walk_mem

> 
> Thanks,
> -Takahiro AKASHI
> 
> > 
> > > 
> > > 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

Thanks
Dave

  reply	other threads:[~2018-07-17  7:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-11  7:41 [PATCH v11 00/15] subject: arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 01/15] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 02/15] kexec_file: make kexec_image_post_load_cleanup_default() global AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 03/15] powerpc, kexec_file: factor out memblock-based arch_kexec_walk_mem() AKASHI Takahiro
2018-07-14  1:52   ` Dave Young
2018-07-16 11:04     ` James Morse
2018-07-16 12:24       ` Dave Young
2018-07-17  5:31         ` AKASHI Takahiro
2018-07-17  7:49           ` Dave Young [this message]
2018-07-18  5:38             ` AKASHI Takahiro
2018-07-18  6:13               ` Dave Young
2018-07-18  6:40                 ` AKASHI Takahiro
2018-07-18  6:45                   ` Dave Young
2018-07-20  5:33                     ` AKASHI Takahiro
2018-07-20  5:57                       ` Dave Young
2018-07-20  6:25                         ` AKASHI Takahiro
2018-07-16 12:26   ` Dave Young
2018-07-18 16:52     ` James Morse
2018-07-19  2:23       ` Dave Young
2018-07-11  7:41 ` [PATCH v11 04/15] kexec_file: kexec_walk_memblock() only walks a dedicated region at kdump AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 05/15] of/fdt: add helper functions for handling properties AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 06/15] arm64: add image head flag definitions AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 07/15] arm64: cpufeature: add MMFR0 helper functions AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 08/15] arm64: enable KEXEC_FILE config AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 09/15] arm64: kexec_file: load initrd and device-tree AKASHI Takahiro
2018-07-17 16:57   ` James Morse
2018-07-18  5:56     ` AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 10/15] arm64: kexec_file: allow for loading Image-format kernel AKASHI Takahiro
2018-07-18 16:47   ` James Morse
2018-07-20  6:14     ` AKASHI Takahiro
2018-07-11  7:41 ` [PATCH v11 11/15] arm64: kexec_file: add crash dump support AKASHI Takahiro
2018-07-18 16:50   ` James Morse
2018-07-23  5:39     ` AKASHI Takahiro
2018-07-23 17:04       ` James Morse
2018-07-11  7:42 ` [PATCH v11 12/15] arm64: kexec_file: invoke the kernel without purgatory AKASHI Takahiro
2018-07-11  7:42 ` [PATCH v11 13/15] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2018-07-11  7:42 ` [PATCH v11 14/15] arm64: kexec_file: add kernel signature verification support AKASHI Takahiro
2018-07-11  7:42 ` [PATCH v11 15/15] arm64: kexec_file: add kaslr support AKASHI Takahiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180717074923.GA8591@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bhe@redhat.com \
    --cc=bhsharma@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=vgoyal@redhat.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).