All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Julien Thierry <julien.thierry@arm.com>
Cc: herbert@gondor.apana.org.au, bhe@redhat.com,
	ard.biesheuvel@linaro.org, catalin.marinas@arm.com,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	kexec@lists.infradead.org, dhowells@redhat.com,
	Linus Torvalds <torvalds@linux-foundation.org>,
	arnd@arndb.de, linux-arm-kernel@lists.infradead.org,
	mpe@ellerman.id.au, bauerman@linux.vnet.ibm.com,
	akpm@linux-foundation.org, dyoung@redhat.com,
	davem@davemloft.net, vgoyal@redhat.com
Subject: Re: [PATCH v4 02/10] resource: add walk_system_ram_res_rev()
Date: Fri, 6 Oct 2017 16:01:42 +0900	[thread overview]
Message-ID: <20171006070140.GA6756@linaro.org> (raw)
In-Reply-To: <f91538fe-986b-5815-b271-e4d7ee8aff4e@arm.com>

Hi Julien,

On Thu, Oct 05, 2017 at 10:36:47AM +0100, Julien Thierry wrote:
> Hi Takahiro,
> 
> On 02/10/17 07:14, AKASHI Takahiro wrote:
> >This function, being a variant of walk_system_ram_res() introduced in
> >commit 8c86e70acead ("resource: provide new functions to walk through
> >resources"), walks through a list of all the resources of System RAM
> >in reversed order, i.e., from higher to lower.
> >
> >It will be used in kexec_file implementation on arm64.
> >
> >Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >Cc: Vivek Goyal <vgoyal@redhat.com>
> >Cc: Andrew Morton <akpm@linux-foundation.org>
> >Cc: Linus Torvalds <torvalds@linux-foundation.org>
> >---
> >  include/linux/ioport.h |  3 +++
> >  kernel/resource.c      | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 62 insertions(+)
> >
> >diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> >index f5cf32e80041..62eb62b98118 100644
> >--- a/include/linux/ioport.h
> >+++ b/include/linux/ioport.h
> >@@ -273,6 +273,9 @@ extern int
> >  walk_system_ram_res(u64 start, u64 end, void *arg,
> >  		    int (*func)(u64, u64, void *));
> >  extern int
> >+walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> >+			int (*func)(u64, u64, void *));
> >+extern int
> >  walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 end,
> >  		    void *arg, int (*func)(u64, u64, void *));
> >diff --git a/kernel/resource.c b/kernel/resource.c
> >index 9b5f04404152..572f2f91ce9c 100644
> >--- a/kernel/resource.c
> >+++ b/kernel/resource.c
> >@@ -23,6 +23,8 @@
> >  #include <linux/pfn.h>
> >  #include <linux/mm.h>
> >  #include <linux/resource_ext.h>
> >+#include <linux/string.h>
> >+#include <linux/vmalloc.h>
> >  #include <asm/io.h>
> >@@ -469,6 +471,63 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
> >  	return ret;
> >  }
> >+int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> >+				int (*func)(u64, u64, void *))
> >+{
> >+	struct resource res, *rams;
> >+	u64 orig_end;
> 
> nit:
> Why do you need orig_end? From what I can tell it is always equal to the
> "end" parameter of the function.

Right, but all the other functions, including walk_system_ram_res()
and walk_iomem_res_desc(), use orig_end in the exact same way.

> If you think having orig_end makes it clearer to distinguish "end" from
> "res.end" could we declare it as:
> 
> 	const u64 orig_end = end;
> 
> Making it clear it is an alias?

That said, I will remove orig_end from my function.

> >+	int count, i;
> >+	int ret = -1;
> >+
> >+	count = 16; /* initial */
> 
> nit:
> This doesn't represent the number of element we found but the size of the
> rams array.
> Would it be better named something like "rams_size"?

Okay

> >+
> >+	/* create a list */
> >+	rams = vmalloc(sizeof(struct resource) * count);
> >+	if (!rams)
> >+		return ret;
> >+
> >+	res.start = start;
> >+	res.end = end;
> >+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >+	orig_end = res.end;
> >+	i = 0;
> >+	while ((res.start < res.end) &&
> >+		(!find_next_iomem_res(&res, IORES_DESC_NONE, true))) {
> >+		if (i >= count) {
> >+			/* re-alloc */
> >+			struct resource *rams_new;
> >+			int count_new;
> >+
> >+			count_new = count + 16;
> >+			rams_new = vmalloc(sizeof(struct resource) * count_new);
> >+			if (!rams_new)
> >+				goto out;
> 
> Should we return -ENOMEM?

Well, I'd like to keep the current code as all the other variants just
return -1 for error.

> >+
> >+			memcpy(rams_new, rams, count);
> 
> We are likely to lose data here.
> 
> -> memcpy(rams_new, rams, count * sizeof(struct resourse));

Oops, thanks.

> Also, if vremalloc doesn't exist maybe the realloc part could still be put
> in a separate function?

Next time :)

Thanks,
-Takahiro AKASHI

> >+			vfree(rams);
> >+			rams = rams_new;
> >+			count = count_new;
> >+		}
> >+
> >+		rams[i].start = res.start;
> >+		rams[i++].end = res.end;
> >+
> >+		res.start = res.end + 1;
> >+		res.end = orig_end;
> >+	}
> >+
> >+	/* go reverse */
> >+	for (i--; i >= 0; i--) {
> >+		ret = (*func)(rams[i].start, rams[i].end, arg);
> >+		if (ret)
> >+			break;
> >+	}
> >+
> >+out:
> >+	vfree(rams);
> >+	return ret;
> >+}
> >+
> >  #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
> >  /*
> >
> 
> Cheers,
> 
> -- 
> Julien Thierry

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 02/10] resource: add walk_system_ram_res_rev()
Date: Fri, 6 Oct 2017 16:01:42 +0900	[thread overview]
Message-ID: <20171006070140.GA6756@linaro.org> (raw)
In-Reply-To: <f91538fe-986b-5815-b271-e4d7ee8aff4e@arm.com>

Hi Julien,

On Thu, Oct 05, 2017 at 10:36:47AM +0100, Julien Thierry wrote:
> Hi Takahiro,
> 
> On 02/10/17 07:14, AKASHI Takahiro wrote:
> >This function, being a variant of walk_system_ram_res() introduced in
> >commit 8c86e70acead ("resource: provide new functions to walk through
> >resources"), walks through a list of all the resources of System RAM
> >in reversed order, i.e., from higher to lower.
> >
> >It will be used in kexec_file implementation on arm64.
> >
> >Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >Cc: Vivek Goyal <vgoyal@redhat.com>
> >Cc: Andrew Morton <akpm@linux-foundation.org>
> >Cc: Linus Torvalds <torvalds@linux-foundation.org>
> >---
> >  include/linux/ioport.h |  3 +++
> >  kernel/resource.c      | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 62 insertions(+)
> >
> >diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> >index f5cf32e80041..62eb62b98118 100644
> >--- a/include/linux/ioport.h
> >+++ b/include/linux/ioport.h
> >@@ -273,6 +273,9 @@ extern int
> >  walk_system_ram_res(u64 start, u64 end, void *arg,
> >  		    int (*func)(u64, u64, void *));
> >  extern int
> >+walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> >+			int (*func)(u64, u64, void *));
> >+extern int
> >  walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 end,
> >  		    void *arg, int (*func)(u64, u64, void *));
> >diff --git a/kernel/resource.c b/kernel/resource.c
> >index 9b5f04404152..572f2f91ce9c 100644
> >--- a/kernel/resource.c
> >+++ b/kernel/resource.c
> >@@ -23,6 +23,8 @@
> >  #include <linux/pfn.h>
> >  #include <linux/mm.h>
> >  #include <linux/resource_ext.h>
> >+#include <linux/string.h>
> >+#include <linux/vmalloc.h>
> >  #include <asm/io.h>
> >@@ -469,6 +471,63 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
> >  	return ret;
> >  }
> >+int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> >+				int (*func)(u64, u64, void *))
> >+{
> >+	struct resource res, *rams;
> >+	u64 orig_end;
> 
> nit:
> Why do you need orig_end? From what I can tell it is always equal to the
> "end" parameter of the function.

Right, but all the other functions, including walk_system_ram_res()
and walk_iomem_res_desc(), use orig_end in the exact same way.

> If you think having orig_end makes it clearer to distinguish "end" from
> "res.end" could we declare it as:
> 
> 	const u64 orig_end = end;
> 
> Making it clear it is an alias?

That said, I will remove orig_end from my function.

> >+	int count, i;
> >+	int ret = -1;
> >+
> >+	count = 16; /* initial */
> 
> nit:
> This doesn't represent the number of element we found but the size of the
> rams array.
> Would it be better named something like "rams_size"?

Okay

> >+
> >+	/* create a list */
> >+	rams = vmalloc(sizeof(struct resource) * count);
> >+	if (!rams)
> >+		return ret;
> >+
> >+	res.start = start;
> >+	res.end = end;
> >+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >+	orig_end = res.end;
> >+	i = 0;
> >+	while ((res.start < res.end) &&
> >+		(!find_next_iomem_res(&res, IORES_DESC_NONE, true))) {
> >+		if (i >= count) {
> >+			/* re-alloc */
> >+			struct resource *rams_new;
> >+			int count_new;
> >+
> >+			count_new = count + 16;
> >+			rams_new = vmalloc(sizeof(struct resource) * count_new);
> >+			if (!rams_new)
> >+				goto out;
> 
> Should we return -ENOMEM?

Well, I'd like to keep the current code as all the other variants just
return -1 for error.

> >+
> >+			memcpy(rams_new, rams, count);
> 
> We are likely to lose data here.
> 
> -> memcpy(rams_new, rams, count * sizeof(struct resourse));

Oops, thanks.

> Also, if vremalloc doesn't exist maybe the realloc part could still be put
> in a separate function?

Next time :)

Thanks,
-Takahiro AKASHI

> >+			vfree(rams);
> >+			rams = rams_new;
> >+			count = count_new;
> >+		}
> >+
> >+		rams[i].start = res.start;
> >+		rams[i++].end = res.end;
> >+
> >+		res.start = res.end + 1;
> >+		res.end = orig_end;
> >+	}
> >+
> >+	/* go reverse */
> >+	for (i--; i >= 0; i--) {
> >+		ret = (*func)(rams[i].start, rams[i].end, arg);
> >+		if (ret)
> >+			break;
> >+	}
> >+
> >+out:
> >+	vfree(rams);
> >+	return ret;
> >+}
> >+
> >  #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
> >  /*
> >
> 
> Cheers,
> 
> -- 
> Julien Thierry

WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Julien Thierry <julien.thierry@arm.com>
Cc: catalin.marinas@arm.com, will.deacon@arm.com,
	bauerman@linux.vnet.ibm.com, dhowells@redhat.com,
	vgoyal@redhat.com, herbert@gondor.apana.org.au,
	davem@davemloft.net, akpm@linux-foundation.org,
	mpe@ellerman.id.au, dyoung@redhat.com, bhe@redhat.com,
	arnd@arndb.de, ard.biesheuvel@linaro.org,
	kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v4 02/10] resource: add walk_system_ram_res_rev()
Date: Fri, 6 Oct 2017 16:01:42 +0900	[thread overview]
Message-ID: <20171006070140.GA6756@linaro.org> (raw)
In-Reply-To: <f91538fe-986b-5815-b271-e4d7ee8aff4e@arm.com>

Hi Julien,

On Thu, Oct 05, 2017 at 10:36:47AM +0100, Julien Thierry wrote:
> Hi Takahiro,
> 
> On 02/10/17 07:14, AKASHI Takahiro wrote:
> >This function, being a variant of walk_system_ram_res() introduced in
> >commit 8c86e70acead ("resource: provide new functions to walk through
> >resources"), walks through a list of all the resources of System RAM
> >in reversed order, i.e., from higher to lower.
> >
> >It will be used in kexec_file implementation on arm64.
> >
> >Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >Cc: Vivek Goyal <vgoyal@redhat.com>
> >Cc: Andrew Morton <akpm@linux-foundation.org>
> >Cc: Linus Torvalds <torvalds@linux-foundation.org>
> >---
> >  include/linux/ioport.h |  3 +++
> >  kernel/resource.c      | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 62 insertions(+)
> >
> >diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> >index f5cf32e80041..62eb62b98118 100644
> >--- a/include/linux/ioport.h
> >+++ b/include/linux/ioport.h
> >@@ -273,6 +273,9 @@ extern int
> >  walk_system_ram_res(u64 start, u64 end, void *arg,
> >  		    int (*func)(u64, u64, void *));
> >  extern int
> >+walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> >+			int (*func)(u64, u64, void *));
> >+extern int
> >  walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64 end,
> >  		    void *arg, int (*func)(u64, u64, void *));
> >diff --git a/kernel/resource.c b/kernel/resource.c
> >index 9b5f04404152..572f2f91ce9c 100644
> >--- a/kernel/resource.c
> >+++ b/kernel/resource.c
> >@@ -23,6 +23,8 @@
> >  #include <linux/pfn.h>
> >  #include <linux/mm.h>
> >  #include <linux/resource_ext.h>
> >+#include <linux/string.h>
> >+#include <linux/vmalloc.h>
> >  #include <asm/io.h>
> >@@ -469,6 +471,63 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
> >  	return ret;
> >  }
> >+int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> >+				int (*func)(u64, u64, void *))
> >+{
> >+	struct resource res, *rams;
> >+	u64 orig_end;
> 
> nit:
> Why do you need orig_end? From what I can tell it is always equal to the
> "end" parameter of the function.

Right, but all the other functions, including walk_system_ram_res()
and walk_iomem_res_desc(), use orig_end in the exact same way.

> If you think having orig_end makes it clearer to distinguish "end" from
> "res.end" could we declare it as:
> 
> 	const u64 orig_end = end;
> 
> Making it clear it is an alias?

That said, I will remove orig_end from my function.

> >+	int count, i;
> >+	int ret = -1;
> >+
> >+	count = 16; /* initial */
> 
> nit:
> This doesn't represent the number of element we found but the size of the
> rams array.
> Would it be better named something like "rams_size"?

Okay

> >+
> >+	/* create a list */
> >+	rams = vmalloc(sizeof(struct resource) * count);
> >+	if (!rams)
> >+		return ret;
> >+
> >+	res.start = start;
> >+	res.end = end;
> >+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >+	orig_end = res.end;
> >+	i = 0;
> >+	while ((res.start < res.end) &&
> >+		(!find_next_iomem_res(&res, IORES_DESC_NONE, true))) {
> >+		if (i >= count) {
> >+			/* re-alloc */
> >+			struct resource *rams_new;
> >+			int count_new;
> >+
> >+			count_new = count + 16;
> >+			rams_new = vmalloc(sizeof(struct resource) * count_new);
> >+			if (!rams_new)
> >+				goto out;
> 
> Should we return -ENOMEM?

Well, I'd like to keep the current code as all the other variants just
return -1 for error.

> >+
> >+			memcpy(rams_new, rams, count);
> 
> We are likely to lose data here.
> 
> -> memcpy(rams_new, rams, count * sizeof(struct resourse));

Oops, thanks.

> Also, if vremalloc doesn't exist maybe the realloc part could still be put
> in a separate function?

Next time :)

Thanks,
-Takahiro AKASHI

> >+			vfree(rams);
> >+			rams = rams_new;
> >+			count = count_new;
> >+		}
> >+
> >+		rams[i].start = res.start;
> >+		rams[i++].end = res.end;
> >+
> >+		res.start = res.end + 1;
> >+		res.end = orig_end;
> >+	}
> >+
> >+	/* go reverse */
> >+	for (i--; i >= 0; i--) {
> >+		ret = (*func)(rams[i].start, rams[i].end, arg);
> >+		if (ret)
> >+			break;
> >+	}
> >+
> >+out:
> >+	vfree(rams);
> >+	return ret;
> >+}
> >+
> >  #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
> >  /*
> >
> 
> Cheers,
> 
> -- 
> Julien Thierry

  reply	other threads:[~2017-10-06  6:59 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02  6:14 [PATCH v4 00/10] arm64: kexec: add kexec_file_load() support AKASHI Takahiro
2017-10-02  6:14 ` AKASHI Takahiro
2017-10-02  6:14 ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 01/10] include: pe.h: remove message[] from mz header definition AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 02/10] resource: add walk_system_ram_res_rev() AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-05  9:36   ` Julien Thierry
2017-10-05  9:36     ` Julien Thierry
2017-10-05  9:36     ` Julien Thierry
2017-10-06  7:01     ` AKASHI Takahiro [this message]
2017-10-06  7:01       ` AKASHI Takahiro
2017-10-06  7:01       ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 03/10] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-04  9:08   ` kbuild test robot
2017-10-04  9:08     ` kbuild test robot
2017-10-04  9:08     ` kbuild test robot
2017-10-04  9:40   ` kbuild test robot
2017-10-04  9:40     ` kbuild test robot
2017-10-04  9:40     ` kbuild test robot
2017-10-05 10:21   ` Julien Thierry
2017-10-05 10:21     ` Julien Thierry
2017-10-05 10:21     ` Julien Thierry
2017-10-06  7:06     ` AKASHI Takahiro
2017-10-06  7:06       ` AKASHI Takahiro
2017-10-06  7:06       ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 04/10] kexec_file: factor out crashdump elf header function from x86 AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 05/10] asm-generic: add kexec_file_load system call to unistd.h AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 06/10] arm64: kexec_file: create purgatory AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 07/10] arm64: kexec_file: load initrd, device-tree and purgatory segments AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 08/10] arm64: kexec_file: set up for crash dump adding elf core header AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-05 14:15   ` Julien Thierry
2017-10-05 14:15     ` Julien Thierry
2017-10-05 14:15     ` Julien Thierry
2017-10-06  7:11     ` AKASHI Takahiro
2017-10-06  7:11       ` AKASHI Takahiro
2017-10-06  7:11       ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 09/10] arm64: enable KEXEC_FILE config AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14 ` [PATCH v4 10/10] arm64: kexec_file: add Image format support AKASHI Takahiro
2017-10-02  6:14   ` AKASHI Takahiro
2017-10-02  6:14   ` 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=20171006070140.GA6756@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=bhe@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=julien.thierry@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.