[PATCH 01/11] resource: Add System RAM resource type

[PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

I/O resource type, IORESOURCE_MEM, is used for all types of
memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
reserved, and so on.  This requires walk_system_ram_range(),
walk_system_ram_res(), and region_intersects() to use strcmp()
against string "System RAM" to search System RAM ranges in the
iomem table, which is inefficient.  __ioremap_caller() and
reserve_memtype() on x86, for instance, call walk_system_ram_range()
for every request to check if a given range is in System RAM ranges.

However, adding a new I/O resource type for System RAM is not
a viable option [1].  Instead, this patch adds a new modifier
flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].

To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
work continuously for System RAM, resource_ext_type() is added
for extracting extended type bit(s).

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reference[1]: https://lkml.org/lkml/2015/12/3/540
Reference[2]: https://lkml.org/lkml/2015/12/3/582
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 include/linux/ioport.h |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 24bea08..4b65d94 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -49,12 +49,19 @@ struct resource {
 #define IORESOURCE_WINDOW	0x00200000	/* forwarded by bridge */
 #define IORESOURCE_MUXED	0x00400000	/* Resource is software muxed */
 
+#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource extended types */
+#define IORESOURCE_SYSRAM	0x01000000	/* System RAM (modifier) */
+
 #define IORESOURCE_EXCLUSIVE	0x08000000	/* Userland may not map this resource */
+
 #define IORESOURCE_DISABLED	0x10000000
 #define IORESOURCE_UNSET	0x20000000	/* No address assigned yet */
 #define IORESOURCE_AUTO		0x40000000
 #define IORESOURCE_BUSY		0x80000000	/* Driver has marked this resource busy */
 
+/* I/O resource extended types */
+#define IORESOURCE_SYSTEM_RAM		(IORESOURCE_MEM|IORESOURCE_SYSRAM)
+
 /* PnP IRQ specific bits (IORESOURCE_BITS) */
 #define IORESOURCE_IRQ_HIGHEDGE		(1<<0)
 #define IORESOURCE_IRQ_LOWEDGE		(1<<1)
@@ -170,6 +177,10 @@ static inline unsigned long resource_type(const struct resource *res)
 {
 	return res->flags & IORESOURCE_TYPE_BITS;
 }
+static inline unsigned long resource_ext_type(const struct resource *res)
+{
+	return res->flags & IORESOURCE_EXT_TYPE_BITS;
+}
 /* True iff r1 completely contains r2 */
 static inline bool resource_contains(struct resource *r1, struct resource *r2)
 {

[PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

I/O resource type, IORESOURCE_MEM, is used for all types of
memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
reserved, and so on.  This requires walk_system_ram_range(),
walk_system_ram_res(), and region_intersects() to use strcmp()
against string "System RAM" to search System RAM ranges in the
iomem table, which is inefficient.  __ioremap_caller() and
reserve_memtype() on x86, for instance, call walk_system_ram_range()
for every request to check if a given range is in System RAM ranges.

However, adding a new I/O resource type for System RAM is not
a viable option [1].  Instead, this patch adds a new modifier
flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].

To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
work continuously for System RAM, resource_ext_type() is added
for extracting extended type bit(s).

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reference[1]: https://lkml.org/lkml/2015/12/3/540
Reference[2]: https://lkml.org/lkml/2015/12/3/582
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 include/linux/ioport.h |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 24bea08..4b65d94 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -49,12 +49,19 @@ struct resource {
 #define IORESOURCE_WINDOW	0x00200000	/* forwarded by bridge */
 #define IORESOURCE_MUXED	0x00400000	/* Resource is software muxed */
 
+#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource extended types */
+#define IORESOURCE_SYSRAM	0x01000000	/* System RAM (modifier) */
+
 #define IORESOURCE_EXCLUSIVE	0x08000000	/* Userland may not map this resource */
+
 #define IORESOURCE_DISABLED	0x10000000
 #define IORESOURCE_UNSET	0x20000000	/* No address assigned yet */
 #define IORESOURCE_AUTO		0x40000000
 #define IORESOURCE_BUSY		0x80000000	/* Driver has marked this resource busy */
 
+/* I/O resource extended types */
+#define IORESOURCE_SYSTEM_RAM		(IORESOURCE_MEM|IORESOURCE_SYSRAM)
+
 /* PnP IRQ specific bits (IORESOURCE_BITS) */
 #define IORESOURCE_IRQ_HIGHEDGE		(1<<0)
 #define IORESOURCE_IRQ_LOWEDGE		(1<<1)
@@ -170,6 +177,10 @@ static inline unsigned long resource_type(const struct resource *res)
 {
 	return res->flags & IORESOURCE_TYPE_BITS;
 }
+static inline unsigned long resource_ext_type(const struct resource *res)
+{
+	return res->flags & IORESOURCE_EXT_TYPE_BITS;
+}
 /* True iff r1 completely contains r2 */
 static inline bool resource_contains(struct resource *r1, struct resource *r2)
 {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 02/11] resource: make resource flags handled properly

[Toshi Kani]

I/O resource flags consist of I/O resource types and modifier
bits.  Therefore, checking I/O resource type of the flags must
be performed with a bitwise operation.

Fix find_next_iomem_res() and region_intersects() that simply
compare the flags against a given value.

Also change __request_region() to set res->flags from
resource_type() and resource_ext_type() of the parent, so that
children nodes will inherit the extended I/O resource type.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reference: https://lkml.org/lkml/2015/12/3/582
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 kernel/resource.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index f150dbb..d30a175 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -358,7 +358,7 @@ static int find_next_iomem_res(struct resource *res, char *name,
 	read_lock(&resource_lock);
 
 	for (p = iomem_resource.child; p; p = next_resource(p, sibling_only)) {
-		if (p->flags != res->flags)
+		if ((p->flags & res->flags) != res->flags)
 			continue;
 		if (name && strcmp(p->name, name))
 			continue;
@@ -519,7 +519,8 @@ int region_intersects(resource_size_t start, size_t size, const char *name)
 
 	read_lock(&resource_lock);
 	for (p = iomem_resource.child; p ; p = p->sibling) {
-		bool is_type = strcmp(p->name, name) == 0 && p->flags == flags;
+		bool is_type = strcmp(p->name, name) == 0 &&
+				((p->flags & flags) == flags);
 
 		if (start >= p->start && start <= p->end)
 			is_type ? type++ : other++;
@@ -1071,7 +1072,7 @@ struct resource * __request_region(struct resource *parent,
 	res->name = name;
 	res->start = start;
 	res->end = start + n - 1;
-	res->flags = resource_type(parent);
+	res->flags = resource_type(parent) | resource_ext_type(parent);
 	res->flags |= IORESOURCE_BUSY | flags;
 
 	write_lock(&resource_lock);

[PATCH 02/11] resource: make resource flags handled properly

[Toshi Kani]

I/O resource flags consist of I/O resource types and modifier
bits.  Therefore, checking I/O resource type of the flags must
be performed with a bitwise operation.

Fix find_next_iomem_res() and region_intersects() that simply
compare the flags against a given value.

Also change __request_region() to set res->flags from
resource_type() and resource_ext_type() of the parent, so that
children nodes will inherit the extended I/O resource type.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reference: https://lkml.org/lkml/2015/12/3/582
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 kernel/resource.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index f150dbb..d30a175 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -358,7 +358,7 @@ static int find_next_iomem_res(struct resource *res, char *name,
 	read_lock(&resource_lock);
 
 	for (p = iomem_resource.child; p; p = next_resource(p, sibling_only)) {
-		if (p->flags != res->flags)
+		if ((p->flags & res->flags) != res->flags)
 			continue;
 		if (name && strcmp(p->name, name))
 			continue;
@@ -519,7 +519,8 @@ int region_intersects(resource_size_t start, size_t size, const char *name)
 
 	read_lock(&resource_lock);
 	for (p = iomem_resource.child; p ; p = p->sibling) {
-		bool is_type = strcmp(p->name, name) == 0 && p->flags == flags;
+		bool is_type = strcmp(p->name, name) == 0 &&
+				((p->flags & flags) == flags);
 
 		if (start >= p->start && start <= p->end)
 			is_type ? type++ : other++;
@@ -1071,7 +1072,7 @@ struct resource * __request_region(struct resource *parent,
 	res->name = name;
 	res->start = start;
 	res->end = start + n - 1;
-	res->flags = resource_type(parent);
+	res->flags = resource_type(parent) | resource_ext_type(parent);
 	res->flags |= IORESOURCE_BUSY | flags;
 
 	write_lock(&resource_lock);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 03/11] x86/e820: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Change e820_reserve_resources() to set IORESOURCE_SYSTEM_RAM for
E820_RESERVED_KERN and E820_RAM, which are set to "System RAM".

Also set IORESOURCE_SYSTEM_RAM to "Kernel data", "Kernel code",
and "Kernel bss", which are children nodes of System RAM.

Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/x86/kernel/e820.c  |   18 +++++++++++++++++-
 arch/x86/kernel/setup.c |    6 +++---
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 569c1e4..4c8bcbc 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -925,6 +925,22 @@ static const char *e820_type_to_string(int e820_type)
 	}
 }
 
+static int e820_type_to_iomem_type(int e820_type)
+{
+	switch (e820_type) {
+	case E820_RESERVED_KERN:
+	case E820_RAM:
+		return IORESOURCE_SYSTEM_RAM;
+	case E820_ACPI:
+	case E820_NVS:
+	case E820_UNUSABLE:
+	case E820_PRAM:
+	case E820_PMEM:
+	default:
+		return IORESOURCE_MEM;
+	}
+}
+
 static bool do_mark_busy(u32 type, struct resource *res)
 {
 	/* this is the legacy bios/dos rom-shadow + mmio region */
@@ -967,7 +983,7 @@ void __init e820_reserve_resources(void)
 		res->start = e820.map[i].addr;
 		res->end = end;
 
-		res->flags = IORESOURCE_MEM;
+		res->flags = e820_type_to_iomem_type(e820.map[i].type);
 
 		/*
 		 * don't register the region that could be conflicted with
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d2bbe34..a492c30 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -152,21 +152,21 @@ static struct resource data_resource = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 

[PATCH 03/11] x86/e820: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Change e820_reserve_resources() to set IORESOURCE_SYSTEM_RAM for
E820_RESERVED_KERN and E820_RAM, which are set to "System RAM".

Also set IORESOURCE_SYSTEM_RAM to "Kernel data", "Kernel code",
and "Kernel bss", which are children nodes of System RAM.

Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/x86/kernel/e820.c  |   18 +++++++++++++++++-
 arch/x86/kernel/setup.c |    6 +++---
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 569c1e4..4c8bcbc 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -925,6 +925,22 @@ static const char *e820_type_to_string(int e820_type)
 	}
 }
 
+static int e820_type_to_iomem_type(int e820_type)
+{
+	switch (e820_type) {
+	case E820_RESERVED_KERN:
+	case E820_RAM:
+		return IORESOURCE_SYSTEM_RAM;
+	case E820_ACPI:
+	case E820_NVS:
+	case E820_UNUSABLE:
+	case E820_PRAM:
+	case E820_PMEM:
+	default:
+		return IORESOURCE_MEM;
+	}
+}
+
 static bool do_mark_busy(u32 type, struct resource *res)
 {
 	/* this is the legacy bios/dos rom-shadow + mmio region */
@@ -967,7 +983,7 @@ void __init e820_reserve_resources(void)
 		res->start = e820.map[i].addr;
 		res->end = end;
 
-		res->flags = IORESOURCE_MEM;
+		res->flags = e820_type_to_iomem_type(e820.map[i].type);
 
 		/*
 		 * don't register the region that could be conflicted with
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d2bbe34..a492c30 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -152,21 +152,21 @@ static struct resource data_resource = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 04/11] arch: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of resource ranges with
"System RAM", "Kernel code", "Kernel data", and "Kernel bss".

Note, IORESOURCE_SYSRAM (i.e. modifier bit) is set to the flags
when IORESOURCE_MEM is already set.  IORESOURCE_SYSTEM_RAM is
defined as (IORESOURCE_MEM|IORESOURCE_SYSRAM).

Note2, Some archs do not set flags for children nodes, such as
"Kernel code".  This patch keeps the flags unset in such cases.

Cc: linux-arch@vger.kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/arm/kernel/setup.c       |    6 +++---
 arch/arm64/kernel/setup.c     |    6 +++---
 arch/avr32/kernel/setup.c     |    6 +++---
 arch/ia64/kernel/efi.c        |    6 ++++--
 arch/ia64/kernel/setup.c      |    6 +++---
 arch/m32r/kernel/setup.c      |    4 ++--
 arch/mips/kernel/setup.c      |   10 ++++++----
 arch/parisc/mm/init.c         |    6 +++---
 arch/powerpc/mm/mem.c         |    2 +-
 arch/s390/kernel/setup.c      |    8 ++++----
 arch/score/kernel/setup.c     |    2 +-
 arch/sh/kernel/setup.c        |    8 ++++----
 arch/sparc/mm/init_64.c       |    8 ++++----
 arch/tile/kernel/setup.c      |   11 ++++++++---
 arch/unicore32/kernel/setup.c |    6 +++---
 15 files changed, 52 insertions(+), 43 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..ae44e09 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -173,13 +173,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -781,7 +781,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		res->name  = "System RAM";
 		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
 		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..450987d 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -73,13 +73,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -210,7 +210,7 @@ static void __init request_standard_resources(void)
 		res->name  = "System RAM";
 		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
 		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 
diff --git a/arch/avr32/kernel/setup.c b/arch/avr32/kernel/setup.c
index 209ae5a..e692889 100644
--- a/arch/avr32/kernel/setup.c
+++ b/arch/avr32/kernel/setup.c
@@ -49,13 +49,13 @@ static struct resource __initdata kernel_data = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_MEM,
+	.flags	= IORESOURCE_SYSTEM_RAM,
 };
 static struct resource __initdata kernel_code = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_MEM,
+	.flags	= IORESOURCE_SYSTEM_RAM,
 	.sibling = &kernel_data,
 };
 
@@ -134,7 +134,7 @@ add_physical_memory(resource_size_t start, resource_size_t end)
 	new->start = start;
 	new->end = end;
 	new->name = "System RAM";
-	new->flags = IORESOURCE_MEM;
+	new->flags = IORESOURCE_SYSTEM_RAM;
 
 	*pprev = new;
 }
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index caae3f4..b6939b0 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -1207,10 +1207,12 @@ efi_initialize_iomem_resources(struct resource *code_resource,
 				if (md->attribute & EFI_MEMORY_WP) {
 					name = "System ROM";
 					flags |= IORESOURCE_READONLY;
-				} else if (md->attribute == EFI_MEMORY_UC)
+				} else if (md->attribute == EFI_MEMORY_UC) {
 					name = "Uncached RAM";
-				else
+				} else {
 					name = "System RAM";
+					flags |= IORESOURCE_SYSRAM;
+				}
 				break;
 
 			case EFI_ACPI_MEMORY_NVS:
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 4f118b0..2029a38 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -80,17 +80,17 @@ unsigned long vga_console_membase;
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 unsigned long ia64_max_cacheline_size;
diff --git a/arch/m32r/kernel/setup.c b/arch/m32r/kernel/setup.c
index 0392112..5f62ff0 100644
--- a/arch/m32r/kernel/setup.c
+++ b/arch/m32r/kernel/setup.c
@@ -70,14 +70,14 @@ static struct resource data_resource = {
 	.name   = "Kernel data",
 	.start  = 0,
 	.end    = 0,
-	.flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name   = "Kernel code",
 	.start  = 0,
 	.end    = 0,
-	.flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 unsigned long memory_start;
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 66aac55..c385af1 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -732,21 +732,23 @@ static void __init resource_init(void)
 			end = HIGHMEM_START - 1;
 
 		res = alloc_bootmem(sizeof(struct resource));
+
+		res->start = start;
+		res->end = end;
+		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+
 		switch (boot_mem_map.map[i].type) {
 		case BOOT_MEM_RAM:
 		case BOOT_MEM_INIT_RAM:
 		case BOOT_MEM_ROM_DATA:
 			res->name = "System RAM";
+			res->flags |= IORESOURCE_SYSRAM;
 			break;
 		case BOOT_MEM_RESERVED:
 		default:
 			res->name = "reserved";
 		}
 
-		res->start = start;
-		res->end = end;
-
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		request_resource(&iomem_resource, res);
 
 		/*
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 1b366c4..3c07d6b 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -55,12 +55,12 @@ signed char pfnnid_map[PFNNID_MAP_MAX] __read_mostly;
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource pdcdata_resource = {
@@ -201,7 +201,7 @@ static void __init setup_bootmem(void)
 		res->name = "System RAM";
 		res->start = pmem_ranges[i].start_pfn << PAGE_SHIFT;
 		res->end = res->start + (pmem_ranges[i].pages << PAGE_SHIFT)-1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 		request_resource(&iomem_resource, res);
 	}
 
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 22d94c3..e78a2b7 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -541,7 +541,7 @@ static int __init add_system_ram_resources(void)
 			res->name = "System RAM";
 			res->start = base;
 			res->end = base + size - 1;
-			res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+			res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 			WARN_ON(request_resource(&iomem_resource, res) < 0);
 		}
 	}
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index c837bca..b65a883 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,17 +376,17 @@ static void __init setup_lowcore(void)
 
 static struct resource code_resource = {
 	.name  = "Kernel code",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource data_resource = {
 	.name = "Kernel data",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource bss_resource = {
 	.name = "Kernel bss",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource __initdata *standard_resources[] = {
@@ -410,7 +410,7 @@ static void __init setup_resources(void)
 
 	for_each_memblock(memory, reg) {
 		res = alloc_bootmem_low(sizeof(*res));
-		res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
 		res->start = reg->base;
diff --git a/arch/score/kernel/setup.c b/arch/score/kernel/setup.c
index b48459a..f3a0649 100644
--- a/arch/score/kernel/setup.c
+++ b/arch/score/kernel/setup.c
@@ -101,7 +101,7 @@ static void __init resource_init(void)
 	res->name = "System RAM";
 	res->start = MEMORY_START;
 	res->end = MEMORY_START + MEMORY_SIZE - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	request_resource(&iomem_resource, res);
 
 	request_resource(res, &code_resource);
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index de19cfa..3f1c18b 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -78,17 +78,17 @@ static char __initdata command_line[COMMAND_LINE_SIZE] = { 0, };
 
 static struct resource code_resource = {
 	.name = "Kernel code",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource data_resource = {
 	.name = "Kernel data",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 unsigned long memory_start;
@@ -202,7 +202,7 @@ void __init __add_active_range(unsigned int nid, unsigned long start_pfn,
 	res->name = "System RAM";
 	res->start = start;
 	res->end = end - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 	if (request_resource(&iomem_resource, res)) {
 		pr_err("unable to request memory_resource 0x%lx 0x%lx\n",
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 3025bd5..a02d43d 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2862,17 +2862,17 @@ void hugetlb_setup(struct pt_regs *regs)
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static inline resource_size_t compute_kern_paddr(void *addr)
@@ -2908,7 +2908,7 @@ static int __init report_memory(void)
 		res->name = "System RAM";
 		res->start = pavail[i].phys_addr;
 		res->end = pavail[i].phys_addr + pavail[i].reg_size - 1;
-		res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		if (insert_resource(&iomem_resource, res) < 0) {
 			pr_warn("Resource insertion failed.\n");
diff --git a/arch/tile/kernel/setup.c b/arch/tile/kernel/setup.c
index 6b755d1..6606fe2 100644
--- a/arch/tile/kernel/setup.c
+++ b/arch/tile/kernel/setup.c
@@ -1632,14 +1632,14 @@ static struct resource data_resource = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 /*
@@ -1673,10 +1673,15 @@ insert_ram_resource(u64 start_pfn, u64 end_pfn, bool reserved)
 		kzalloc(sizeof(struct resource), GFP_ATOMIC);
 	if (!res)
 		return NULL;
-	res->name = reserved ? "Reserved" : "System RAM";
 	res->start = start_pfn << PAGE_SHIFT;
 	res->end = (end_pfn << PAGE_SHIFT) - 1;
 	res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+	if (reserved) {
+		res->name = "Reserved";
+	} else {
+		res->name = "System RAM";
+		res->flags |= IORESOURCE_SYSRAM;
+	}
 	if (insert_resource(&iomem_resource, res)) {
 		kfree(res);
 		return NULL;
diff --git a/arch/unicore32/kernel/setup.c b/arch/unicore32/kernel/setup.c
index 3fa317f..c2bffa5 100644
--- a/arch/unicore32/kernel/setup.c
+++ b/arch/unicore32/kernel/setup.c
@@ -72,13 +72,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -211,7 +211,7 @@ request_standard_resources(struct meminfo *mi)
 		res->name  = "System RAM";
 		res->start = mi->bank[i].start;
 		res->end   = mi->bank[i].start + mi->bank[i].size - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 

[PATCH 04/11] arch: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of resource ranges with
"System RAM", "Kernel code", "Kernel data", and "Kernel bss".

Note, IORESOURCE_SYSRAM (i.e. modifier bit) is set to the flags
when IORESOURCE_MEM is already set.  IORESOURCE_SYSTEM_RAM is
defined as (IORESOURCE_MEM|IORESOURCE_SYSRAM).

Note2, Some archs do not set flags for children nodes, such as
"Kernel code".  This patch keeps the flags unset in such cases.

Cc: linux-arch@vger.kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/arm/kernel/setup.c       |    6 +++---
 arch/arm64/kernel/setup.c     |    6 +++---
 arch/avr32/kernel/setup.c     |    6 +++---
 arch/ia64/kernel/efi.c        |    6 ++++--
 arch/ia64/kernel/setup.c      |    6 +++---
 arch/m32r/kernel/setup.c      |    4 ++--
 arch/mips/kernel/setup.c      |   10 ++++++----
 arch/parisc/mm/init.c         |    6 +++---
 arch/powerpc/mm/mem.c         |    2 +-
 arch/s390/kernel/setup.c      |    8 ++++----
 arch/score/kernel/setup.c     |    2 +-
 arch/sh/kernel/setup.c        |    8 ++++----
 arch/sparc/mm/init_64.c       |    8 ++++----
 arch/tile/kernel/setup.c      |   11 ++++++++---
 arch/unicore32/kernel/setup.c |    6 +++---
 15 files changed, 52 insertions(+), 43 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..ae44e09 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -173,13 +173,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -781,7 +781,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
 		res->name  = "System RAM";
 		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
 		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..450987d 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -73,13 +73,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -210,7 +210,7 @@ static void __init request_standard_resources(void)
 		res->name  = "System RAM";
 		res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
 		res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 
diff --git a/arch/avr32/kernel/setup.c b/arch/avr32/kernel/setup.c
index 209ae5a..e692889 100644
--- a/arch/avr32/kernel/setup.c
+++ b/arch/avr32/kernel/setup.c
@@ -49,13 +49,13 @@ static struct resource __initdata kernel_data = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_MEM,
+	.flags	= IORESOURCE_SYSTEM_RAM,
 };
 static struct resource __initdata kernel_code = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_MEM,
+	.flags	= IORESOURCE_SYSTEM_RAM,
 	.sibling = &kernel_data,
 };
 
@@ -134,7 +134,7 @@ add_physical_memory(resource_size_t start, resource_size_t end)
 	new->start = start;
 	new->end = end;
 	new->name = "System RAM";
-	new->flags = IORESOURCE_MEM;
+	new->flags = IORESOURCE_SYSTEM_RAM;
 
 	*pprev = new;
 }
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index caae3f4..b6939b0 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -1207,10 +1207,12 @@ efi_initialize_iomem_resources(struct resource *code_resource,
 				if (md->attribute & EFI_MEMORY_WP) {
 					name = "System ROM";
 					flags |= IORESOURCE_READONLY;
-				} else if (md->attribute == EFI_MEMORY_UC)
+				} else if (md->attribute == EFI_MEMORY_UC) {
 					name = "Uncached RAM";
-				else
+				} else {
 					name = "System RAM";
+					flags |= IORESOURCE_SYSRAM;
+				}
 				break;
 
 			case EFI_ACPI_MEMORY_NVS:
diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
index 4f118b0..2029a38 100644
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -80,17 +80,17 @@ unsigned long vga_console_membase;
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 unsigned long ia64_max_cacheline_size;
diff --git a/arch/m32r/kernel/setup.c b/arch/m32r/kernel/setup.c
index 0392112..5f62ff0 100644
--- a/arch/m32r/kernel/setup.c
+++ b/arch/m32r/kernel/setup.c
@@ -70,14 +70,14 @@ static struct resource data_resource = {
 	.name   = "Kernel data",
 	.start  = 0,
 	.end    = 0,
-	.flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name   = "Kernel code",
 	.start  = 0,
 	.end    = 0,
-	.flags  = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags  = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 unsigned long memory_start;
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 66aac55..c385af1 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -732,21 +732,23 @@ static void __init resource_init(void)
 			end = HIGHMEM_START - 1;
 
 		res = alloc_bootmem(sizeof(struct resource));
+
+		res->start = start;
+		res->end = end;
+		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+
 		switch (boot_mem_map.map[i].type) {
 		case BOOT_MEM_RAM:
 		case BOOT_MEM_INIT_RAM:
 		case BOOT_MEM_ROM_DATA:
 			res->name = "System RAM";
+			res->flags |= IORESOURCE_SYSRAM;
 			break;
 		case BOOT_MEM_RESERVED:
 		default:
 			res->name = "reserved";
 		}
 
-		res->start = start;
-		res->end = end;
-
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 		request_resource(&iomem_resource, res);
 
 		/*
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 1b366c4..3c07d6b 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -55,12 +55,12 @@ signed char pfnnid_map[PFNNID_MAP_MAX] __read_mostly;
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource pdcdata_resource = {
@@ -201,7 +201,7 @@ static void __init setup_bootmem(void)
 		res->name = "System RAM";
 		res->start = pmem_ranges[i].start_pfn << PAGE_SHIFT;
 		res->end = res->start + (pmem_ranges[i].pages << PAGE_SHIFT)-1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 		request_resource(&iomem_resource, res);
 	}
 
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 22d94c3..e78a2b7 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -541,7 +541,7 @@ static int __init add_system_ram_resources(void)
 			res->name = "System RAM";
 			res->start = base;
 			res->end = base + size - 1;
-			res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+			res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 			WARN_ON(request_resource(&iomem_resource, res) < 0);
 		}
 	}
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index c837bca..b65a883 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -376,17 +376,17 @@ static void __init setup_lowcore(void)
 
 static struct resource code_resource = {
 	.name  = "Kernel code",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource data_resource = {
 	.name = "Kernel data",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource bss_resource = {
 	.name = "Kernel bss",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource __initdata *standard_resources[] = {
@@ -410,7 +410,7 @@ static void __init setup_resources(void)
 
 	for_each_memblock(memory, reg) {
 		res = alloc_bootmem_low(sizeof(*res));
-		res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		res->name = "System RAM";
 		res->start = reg->base;
diff --git a/arch/score/kernel/setup.c b/arch/score/kernel/setup.c
index b48459a..f3a0649 100644
--- a/arch/score/kernel/setup.c
+++ b/arch/score/kernel/setup.c
@@ -101,7 +101,7 @@ static void __init resource_init(void)
 	res->name = "System RAM";
 	res->start = MEMORY_START;
 	res->end = MEMORY_START + MEMORY_SIZE - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	request_resource(&iomem_resource, res);
 
 	request_resource(res, &code_resource);
diff --git a/arch/sh/kernel/setup.c b/arch/sh/kernel/setup.c
index de19cfa..3f1c18b 100644
--- a/arch/sh/kernel/setup.c
+++ b/arch/sh/kernel/setup.c
@@ -78,17 +78,17 @@ static char __initdata command_line[COMMAND_LINE_SIZE] = { 0, };
 
 static struct resource code_resource = {
 	.name = "Kernel code",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource data_resource = {
 	.name = "Kernel data",
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
 };
 
 unsigned long memory_start;
@@ -202,7 +202,7 @@ void __init __add_active_range(unsigned int nid, unsigned long start_pfn,
 	res->name = "System RAM";
 	res->start = start;
 	res->end = end - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 	if (request_resource(&iomem_resource, res)) {
 		pr_err("unable to request memory_resource 0x%lx 0x%lx\n",
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 3025bd5..a02d43d 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2862,17 +2862,17 @@ void hugetlb_setup(struct pt_regs *regs)
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource data_resource = {
 	.name	= "Kernel data",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource bss_resource = {
 	.name	= "Kernel bss",
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static inline resource_size_t compute_kern_paddr(void *addr)
@@ -2908,7 +2908,7 @@ static int __init report_memory(void)
 		res->name = "System RAM";
 		res->start = pavail[i].phys_addr;
 		res->end = pavail[i].phys_addr + pavail[i].reg_size - 1;
-		res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+		res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 
 		if (insert_resource(&iomem_resource, res) < 0) {
 			pr_warn("Resource insertion failed.\n");
diff --git a/arch/tile/kernel/setup.c b/arch/tile/kernel/setup.c
index 6b755d1..6606fe2 100644
--- a/arch/tile/kernel/setup.c
+++ b/arch/tile/kernel/setup.c
@@ -1632,14 +1632,14 @@ static struct resource data_resource = {
 	.name	= "Kernel data",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 static struct resource code_resource = {
 	.name	= "Kernel code",
 	.start	= 0,
 	.end	= 0,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags	= IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 /*
@@ -1673,10 +1673,15 @@ insert_ram_resource(u64 start_pfn, u64 end_pfn, bool reserved)
 		kzalloc(sizeof(struct resource), GFP_ATOMIC);
 	if (!res)
 		return NULL;
-	res->name = reserved ? "Reserved" : "System RAM";
 	res->start = start_pfn << PAGE_SHIFT;
 	res->end = (end_pfn << PAGE_SHIFT) - 1;
 	res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+	if (reserved) {
+		res->name = "Reserved";
+	} else {
+		res->name = "System RAM";
+		res->flags |= IORESOURCE_SYSRAM;
+	}
 	if (insert_resource(&iomem_resource, res)) {
 		kfree(res);
 		return NULL;
diff --git a/arch/unicore32/kernel/setup.c b/arch/unicore32/kernel/setup.c
index 3fa317f..c2bffa5 100644
--- a/arch/unicore32/kernel/setup.c
+++ b/arch/unicore32/kernel/setup.c
@@ -72,13 +72,13 @@ static struct resource mem_res[] = {
 		.name = "Kernel code",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	},
 	{
 		.name = "Kernel data",
 		.start = 0,
 		.end = 0,
-		.flags = IORESOURCE_MEM
+		.flags = IORESOURCE_SYSTEM_RAM
 	}
 };
 
@@ -211,7 +211,7 @@ request_standard_resources(struct meminfo *mi)
 		res->name  = "System RAM";
 		res->start = mi->bank[i].start;
 		res->end   = mi->bank[i].start + mi->bank[i].size - 1;
-		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 		request_resource(&iomem_resource, res);
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 05/11] xen: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of memory hotplug resource
ranges with "System RAM".

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 drivers/xen/balloon.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 12eab50..dc4305b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -257,7 +257,7 @@ static struct resource *additional_memory_resource(phys_addr_t size)
 		return NULL;
 
 	res->name = "System RAM";
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 	ret = allocate_resource(&iomem_resource, res,
 				size, 0, -1,

[PATCH 05/11] xen: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of memory hotplug resource
ranges with "System RAM".

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 drivers/xen/balloon.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 12eab50..dc4305b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -257,7 +257,7 @@ static struct resource *additional_memory_resource(phys_addr_t size)
 		return NULL;
 
 	res->name = "System RAM";
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 	ret = allocate_resource(&iomem_resource, res,
 				size, 0, -1,

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 05/11] xen: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of memory hotplug resource
ranges with "System RAM".

Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 drivers/xen/balloon.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 12eab50..dc4305b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -257,7 +257,7 @@ static struct resource *additional_memory_resource(phys_addr_t size)
 		return NULL;
 
 	res->name = "System RAM";
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
 	ret = allocate_resource(&iomem_resource, res,
 				size, 0, -1,

[PATCH 06/11] kexec: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of resource ranges with
"System RAM", and "Crash kernel", which is a child node of
System RAM.

Change kexec_add_buffer() to call walk_iomem_res() with
IORESOURCE_SYSTEM_RAM type for "Crash kernel".

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 kernel/kexec_core.c |    6 +++---
 kernel/kexec_file.c |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 11b64a6..c47cd98 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -66,13 +66,13 @@ struct resource crashk_res = {
 	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 struct resource crashk_low_res = {
 	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 int kexec_should_crash(struct task_struct *p)
@@ -934,7 +934,7 @@ int crash_shrink_memory(unsigned long new_size)
 
 	ram_res->start = end;
 	ram_res->end = crashk_res.end;
-	ram_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+	ram_res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 	ram_res->name = "System RAM";
 
 	crashk_res.end = end - 1;
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b70ada0..c245085 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -523,7 +523,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer, unsigned long bufsz,
 	/* Walk the RAM ranges and allocate a suitable range for the buffer */
 	if (image->type == KEXEC_TYPE_CRASH)
 		ret = walk_iomem_res("Crash kernel",
-				     IORESOURCE_MEM | IORESOURCE_BUSY,
+				     IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
 				     crashk_res.start, crashk_res.end, kbuf,
 				     locate_mem_hole_callback);
 	else

[PATCH 06/11] kexec: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of resource ranges with
"System RAM", and "Crash kernel", which is a child node of
System RAM.

Change kexec_add_buffer() to call walk_iomem_res() with
IORESOURCE_SYSTEM_RAM type for "Crash kernel".

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 kernel/kexec_core.c |    6 +++---
 kernel/kexec_file.c |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 11b64a6..c47cd98 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -66,13 +66,13 @@ struct resource crashk_res = {
 	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 struct resource crashk_low_res = {
 	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
-	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
+	.flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM
 };
 
 int kexec_should_crash(struct task_struct *p)
@@ -934,7 +934,7 @@ int crash_shrink_memory(unsigned long new_size)
 
 	ram_res->start = end;
 	ram_res->end = crashk_res.end;
-	ram_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+	ram_res->flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM;
 	ram_res->name = "System RAM";
 
 	crashk_res.end = end - 1;
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b70ada0..c245085 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -523,7 +523,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer, unsigned long bufsz,
 	/* Walk the RAM ranges and allocate a suitable range for the buffer */
 	if (image->type == KEXEC_TYPE_CRASH)
 		ret = walk_iomem_res("Crash kernel",
-				     IORESOURCE_MEM | IORESOURCE_BUSY,
+				     IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
 				     crashk_res.start, crashk_res.end, kbuf,
 				     locate_mem_hole_callback);
 	else

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 07/11] memory-hotplug: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of memory hotplug resource
ranges with "System RAM".

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 mm/memory_hotplug.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 67d488a..9458423 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -136,7 +136,7 @@ static struct resource *register_memory_resource(u64 start, u64 size)
 	res->name = "System RAM";
 	res->start = start;
 	res->end = start + size - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	if (request_resource(&iomem_resource, res) < 0) {
 		pr_debug("System RAM resource %pR cannot be added\n", res);
 		kfree(res);

[PATCH 07/11] memory-hotplug: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of memory hotplug resource
ranges with "System RAM".

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 mm/memory_hotplug.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 67d488a..9458423 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -136,7 +136,7 @@ static struct resource *register_memory_resource(u64 start, u64 size)
 	res->name = "System RAM";
 	res->start = start;
 	res->end = start + size - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	if (request_resource(&iomem_resource, res) < 0) {
 		pr_debug("System RAM resource %pR cannot be added\n", res);
 		kfree(res);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 08/11] memremap: Change region_intersects() to use System RAM type

[Toshi Kani]

Change region_intersects() to add @flags, and make @name optinal
with NULL.  When NULL is set to @name, it skips strcmp().

Change the callers of region_intersects(), memremap() and
devm_memremap(), to set IORESOURCE_SYSTEM_RAM to @flags for
searching System RAM.

Also, export region_intersects() so that the EINJ driver can
call this function in a later patch.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 include/linux/mm.h |    3 ++-
 kernel/memremap.c  |   13 +++++++------
 kernel/resource.c  |   25 ++++++++++++++-----------
 3 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 00bad77..d2ee94a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -362,7 +362,8 @@ enum {
 	REGION_MIXED,
 };
 
-int region_intersects(resource_size_t offset, size_t size, const char *type);
+int region_intersects(resource_size_t offset, size_t size, unsigned long flags,
+			const char *name);
 
 /* Support for virtually mapped pages */
 struct page *vmalloc_to_page(const void *addr);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 7658d32..cefd382 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -44,7 +44,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * being mapped does not have i/o side effects and the __iomem
  * annotation is not applicable.
  *
- * MEMREMAP_WB - matches the default mapping for "System RAM" on
+ * MEMREMAP_WB - matches the default mapping for System RAM on
  * the architecture.  This is usually a read-allocate write-back cache.
  * Morever, if MEMREMAP_WB is specified and the requested remap region is RAM
  * memremap() will bypass establishing a new mapping and instead return
@@ -53,11 +53,12 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * MEMREMAP_WT - establish a mapping whereby writes either bypass the
  * cache or are written through to memory and never exist in a
  * cache-dirty state with respect to program visibility.  Attempts to
- * map "System RAM" with this mapping type will fail.
+ * map System RAM with this mapping type will fail.
  */
 void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 {
-	int is_ram = region_intersects(offset, size, "System RAM");
+	int is_ram = region_intersects(offset, size,
+					IORESOURCE_SYSTEM_RAM, NULL);
 	void *addr = NULL;
 
 	if (is_ram == REGION_MIXED) {
@@ -73,7 +74,7 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 		 * MEMREMAP_WB is special in that it can be satisifed
 		 * from the direct map.  Some archs depend on the
 		 * capability of memremap() to autodetect cases where
-		 * the requested range is potentially in "System RAM"
+		 * the requested range is potentially in System RAM.
 		 */
 		if (is_ram == REGION_INTERSECTS)
 			addr = try_ram_remap(offset, size);
@@ -85,7 +86,7 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 	 * If we don't have a mapping yet and more request flags are
 	 * pending then we will be attempting to establish a new virtual
 	 * address mapping.  Enforce that this mapping is not aliasing
-	 * "System RAM"
+	 * System RAM.
 	 */
 	if (!addr && is_ram == REGION_INTERSECTS && flags) {
 		WARN_ONCE(1, "memremap attempted on ram %pa size: %#lx\n",
@@ -163,7 +164,7 @@ static void devm_memremap_pages_release(struct device *dev, void *res)
 void *devm_memremap_pages(struct device *dev, struct resource *res)
 {
 	int is_ram = region_intersects(res->start, resource_size(res),
-			"System RAM");
+					IORESOURCE_SYSTEM_RAM, NULL);
 	struct page_map *page_map;
 	int error, nid;
 
diff --git a/kernel/resource.c b/kernel/resource.c
index d30a175..56bed6d 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -496,31 +496,33 @@ EXPORT_SYMBOL_GPL(page_is_ram);
  * region_intersects() - determine intersection of region with known resources
  * @start: region start address
  * @size: size of region
- * @name: name of resource (in iomem_resource)
+ * @flags: flags of resource (in iomem_resource)
+ * @name: name of resource (in iomem_resource) or NULL
  *
  * Check if the specified region partially overlaps or fully eclipses a
- * resource identified by @name.  Return REGION_DISJOINT if the region
- * does not overlap @name, return REGION_MIXED if the region overlaps
- * @type and another resource, and return REGION_INTERSECTS if the
- * region overlaps @type and no other defined resource. Note, that
- * REGION_INTERSECTS is also returned in the case when the specified
- * region overlaps RAM and undefined memory holes.
+ * resource identified by @flags and @name (optinal with NULL).  Return
+ * REGION_DISJOINT if the region does not overlap @flags/@name, return
+ * REGION_MIXED if the region overlaps @flags/@name and another resource,
+ * and return REGION_INTERSECTS if the region overlaps @flags/@name and
+ * no other defined resource. Note, that REGION_INTERSECTS is also returned
+ * in the case when the specified region overlaps RAM and undefined memory
+ * holes.
  *
  * region_intersect() is used by memory remapping functions to ensure
  * the user is not remapping RAM and is a vast speed up over walking
  * through the resource table page by page.
  */
-int region_intersects(resource_size_t start, size_t size, const char *name)
+int region_intersects(resource_size_t start, size_t size, unsigned long flags,
+			const char *name)
 {
-	unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 	resource_size_t end = start + size - 1;
 	int type = 0; int other = 0;
 	struct resource *p;
 
 	read_lock(&resource_lock);
 	for (p = iomem_resource.child; p ; p = p->sibling) {
-		bool is_type = strcmp(p->name, name) == 0 &&
-				((p->flags & flags) == flags);
+		bool is_type = ((p->flags & flags) == flags) &&
+				(!name || strcmp(p->name, name) == 0);
 
 		if (start >= p->start && start <= p->end)
 			is_type ? type++ : other++;
@@ -539,6 +541,7 @@ int region_intersects(resource_size_t start, size_t size, const char *name)
 
 	return REGION_DISJOINT;
 }
+EXPORT_SYMBOL_GPL(region_intersects);
 
 void __weak arch_remove_reservations(struct resource *avail)
 {

[PATCH 08/11] memremap: Change region_intersects() to use System RAM type

[Toshi Kani]

Change region_intersects() to add @flags, and make @name optinal
with NULL.  When NULL is set to @name, it skips strcmp().

Change the callers of region_intersects(), memremap() and
devm_memremap(), to set IORESOURCE_SYSTEM_RAM to @flags for
searching System RAM.

Also, export region_intersects() so that the EINJ driver can
call this function in a later patch.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 include/linux/mm.h |    3 ++-
 kernel/memremap.c  |   13 +++++++------
 kernel/resource.c  |   25 ++++++++++++++-----------
 3 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 00bad77..d2ee94a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -362,7 +362,8 @@ enum {
 	REGION_MIXED,
 };
 
-int region_intersects(resource_size_t offset, size_t size, const char *type);
+int region_intersects(resource_size_t offset, size_t size, unsigned long flags,
+			const char *name);
 
 /* Support for virtually mapped pages */
 struct page *vmalloc_to_page(const void *addr);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 7658d32..cefd382 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -44,7 +44,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * being mapped does not have i/o side effects and the __iomem
  * annotation is not applicable.
  *
- * MEMREMAP_WB - matches the default mapping for "System RAM" on
+ * MEMREMAP_WB - matches the default mapping for System RAM on
  * the architecture.  This is usually a read-allocate write-back cache.
  * Morever, if MEMREMAP_WB is specified and the requested remap region is RAM
  * memremap() will bypass establishing a new mapping and instead return
@@ -53,11 +53,12 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * MEMREMAP_WT - establish a mapping whereby writes either bypass the
  * cache or are written through to memory and never exist in a
  * cache-dirty state with respect to program visibility.  Attempts to
- * map "System RAM" with this mapping type will fail.
+ * map System RAM with this mapping type will fail.
  */
 void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 {
-	int is_ram = region_intersects(offset, size, "System RAM");
+	int is_ram = region_intersects(offset, size,
+					IORESOURCE_SYSTEM_RAM, NULL);
 	void *addr = NULL;
 
 	if (is_ram == REGION_MIXED) {
@@ -73,7 +74,7 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 		 * MEMREMAP_WB is special in that it can be satisifed
 		 * from the direct map.  Some archs depend on the
 		 * capability of memremap() to autodetect cases where
-		 * the requested range is potentially in "System RAM"
+		 * the requested range is potentially in System RAM.
 		 */
 		if (is_ram == REGION_INTERSECTS)
 			addr = try_ram_remap(offset, size);
@@ -85,7 +86,7 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 	 * If we don't have a mapping yet and more request flags are
 	 * pending then we will be attempting to establish a new virtual
 	 * address mapping.  Enforce that this mapping is not aliasing
-	 * "System RAM"
+	 * System RAM.
 	 */
 	if (!addr && is_ram == REGION_INTERSECTS && flags) {
 		WARN_ONCE(1, "memremap attempted on ram %pa size: %#lx\n",
@@ -163,7 +164,7 @@ static void devm_memremap_pages_release(struct device *dev, void *res)
 void *devm_memremap_pages(struct device *dev, struct resource *res)
 {
 	int is_ram = region_intersects(res->start, resource_size(res),
-			"System RAM");
+					IORESOURCE_SYSTEM_RAM, NULL);
 	struct page_map *page_map;
 	int error, nid;
 
diff --git a/kernel/resource.c b/kernel/resource.c
index d30a175..56bed6d 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -496,31 +496,33 @@ EXPORT_SYMBOL_GPL(page_is_ram);
  * region_intersects() - determine intersection of region with known resources
  * @start: region start address
  * @size: size of region
- * @name: name of resource (in iomem_resource)
+ * @flags: flags of resource (in iomem_resource)
+ * @name: name of resource (in iomem_resource) or NULL
  *
  * Check if the specified region partially overlaps or fully eclipses a
- * resource identified by @name.  Return REGION_DISJOINT if the region
- * does not overlap @name, return REGION_MIXED if the region overlaps
- * @type and another resource, and return REGION_INTERSECTS if the
- * region overlaps @type and no other defined resource. Note, that
- * REGION_INTERSECTS is also returned in the case when the specified
- * region overlaps RAM and undefined memory holes.
+ * resource identified by @flags and @name (optinal with NULL).  Return
+ * REGION_DISJOINT if the region does not overlap @flags/@name, return
+ * REGION_MIXED if the region overlaps @flags/@name and another resource,
+ * and return REGION_INTERSECTS if the region overlaps @flags/@name and
+ * no other defined resource. Note, that REGION_INTERSECTS is also returned
+ * in the case when the specified region overlaps RAM and undefined memory
+ * holes.
  *
  * region_intersect() is used by memory remapping functions to ensure
  * the user is not remapping RAM and is a vast speed up over walking
  * through the resource table page by page.
  */
-int region_intersects(resource_size_t start, size_t size, const char *name)
+int region_intersects(resource_size_t start, size_t size, unsigned long flags,
+			const char *name)
 {
-	unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 	resource_size_t end = start + size - 1;
 	int type = 0; int other = 0;
 	struct resource *p;
 
 	read_lock(&resource_lock);
 	for (p = iomem_resource.child; p ; p = p->sibling) {
-		bool is_type = strcmp(p->name, name) == 0 &&
-				((p->flags & flags) == flags);
+		bool is_type = ((p->flags & flags) == flags) &&
+				(!name || strcmp(p->name, name) == 0);
 
 		if (start >= p->start && start <= p->end)
 			is_type ? type++ : other++;
@@ -539,6 +541,7 @@ int region_intersects(resource_size_t start, size_t size, const char *name)
 
 	return REGION_DISJOINT;
 }
+EXPORT_SYMBOL_GPL(region_intersects);
 
 void __weak arch_remove_reservations(struct resource *avail)
 {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 09/11] resource: Change walk_system_ram to use System RAM type

[Toshi Kani]

Change walk_system_ram_res() and walk_system_ram_range() to
call find_next_iomem_res() by setting IORESOURCE_SYSTEM_RAM
to @res->flags and NULL to @name.  With this change, they
walk through the resource table without doing strcmp().

No functional change is made to the interfaces.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 kernel/resource.c |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 56bed6d..c6f13d0 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -334,8 +334,8 @@ EXPORT_SYMBOL(release_resource);
 
 /*
  * Finds the lowest iomem reosurce exists with-in [res->start.res->end)
- * the caller must specify res->start, res->end, res->flags and "name".
- * If found, returns 0, res is overwritten, if not found, returns -1.
+ * the caller must specify res->start, res->end, res->flags and optionally
+ * "name".  If found, returns 0, res is overwritten, if not found, returns -1.
  * This walks through whole tree and not just first level children
  * until and unless first_level_children_only is true.
  */
@@ -415,9 +415,9 @@ int walk_iomem_res(char *name, unsigned long flags, u64 start, u64 end,
 }
 
 /*
- * This function calls callback against all memory range of "System RAM"
- * which are marked as IORESOURCE_MEM and IORESOUCE_BUSY.
- * Now, this function is only for "System RAM". This function deals with
+ * This function calls callback against all memory range of System RAM
+ * which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
+ * Now, this function is only for System RAM. This function deals with
  * full ranges and not pfn. If resources are not pfn aligned, dealing
  * with pfn can truncate ranges.
  */
@@ -430,10 +430,10 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 
 	res.start = start;
 	res.end = end;
-	res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	orig_end = res.end;
 	while ((res.start < res.end) &&
-		(!find_next_iomem_res(&res, "System RAM", true))) {
+		(!find_next_iomem_res(&res, NULL, true))) {
 		ret = (*func)(res.start, res.end, arg);
 		if (ret)
 			break;
@@ -446,9 +446,9 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
 
 /*
- * This function calls callback against all memory range of "System RAM"
- * which are marked as IORESOURCE_MEM and IORESOUCE_BUSY.
- * Now, this function is only for "System RAM".
+ * This function calls callback against all memory range of System RAM
+ * which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
+ * Now, this function is only for System RAM.
  */
 int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
 		void *arg, int (*func)(unsigned long, unsigned long, void *))
@@ -460,10 +460,10 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
 
 	res.start = (u64) start_pfn << PAGE_SHIFT;
 	res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
-	res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	orig_end = res.end;
 	while ((res.start < res.end) &&
-		(find_next_iomem_res(&res, "System RAM", true) >= 0)) {
+		(find_next_iomem_res(&res, NULL, true) >= 0)) {
 		pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
 		end_pfn = (res.end + 1) >> PAGE_SHIFT;
 		if (end_pfn > pfn)
@@ -484,7 +484,7 @@ static int __is_ram(unsigned long pfn, unsigned long nr_pages, void *arg)
 }
 /*
  * This generic page_is_ram() returns true if specified address is
- * registered as "System RAM" in iomem_resource list.
+ * registered as System RAM in iomem_resource list.
  */
 int __weak page_is_ram(unsigned long pfn)
 {

[PATCH 09/11] resource: Change walk_system_ram to use System RAM type

[Toshi Kani]

Change walk_system_ram_res() and walk_system_ram_range() to
call find_next_iomem_res() by setting IORESOURCE_SYSTEM_RAM
to @res->flags and NULL to @name.  With this change, they
walk through the resource table without doing strcmp().

No functional change is made to the interfaces.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 kernel/resource.c |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 56bed6d..c6f13d0 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -334,8 +334,8 @@ EXPORT_SYMBOL(release_resource);
 
 /*
  * Finds the lowest iomem reosurce exists with-in [res->start.res->end)
- * the caller must specify res->start, res->end, res->flags and "name".
- * If found, returns 0, res is overwritten, if not found, returns -1.
+ * the caller must specify res->start, res->end, res->flags and optionally
+ * "name".  If found, returns 0, res is overwritten, if not found, returns -1.
  * This walks through whole tree and not just first level children
  * until and unless first_level_children_only is true.
  */
@@ -415,9 +415,9 @@ int walk_iomem_res(char *name, unsigned long flags, u64 start, u64 end,
 }
 
 /*
- * This function calls callback against all memory range of "System RAM"
- * which are marked as IORESOURCE_MEM and IORESOUCE_BUSY.
- * Now, this function is only for "System RAM". This function deals with
+ * This function calls callback against all memory range of System RAM
+ * which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
+ * Now, this function is only for System RAM. This function deals with
  * full ranges and not pfn. If resources are not pfn aligned, dealing
  * with pfn can truncate ranges.
  */
@@ -430,10 +430,10 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 
 	res.start = start;
 	res.end = end;
-	res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	orig_end = res.end;
 	while ((res.start < res.end) &&
-		(!find_next_iomem_res(&res, "System RAM", true))) {
+		(!find_next_iomem_res(&res, NULL, true))) {
 		ret = (*func)(res.start, res.end, arg);
 		if (ret)
 			break;
@@ -446,9 +446,9 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
 #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
 
 /*
- * This function calls callback against all memory range of "System RAM"
- * which are marked as IORESOURCE_MEM and IORESOUCE_BUSY.
- * Now, this function is only for "System RAM".
+ * This function calls callback against all memory range of System RAM
+ * which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
+ * Now, this function is only for System RAM.
  */
 int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
 		void *arg, int (*func)(unsigned long, unsigned long, void *))
@@ -460,10 +460,10 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
 
 	res.start = (u64) start_pfn << PAGE_SHIFT;
 	res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
-	res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 	orig_end = res.end;
 	while ((res.start < res.end) &&
-		(find_next_iomem_res(&res, "System RAM", true) >= 0)) {
+		(find_next_iomem_res(&res, NULL, true) >= 0)) {
 		pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
 		end_pfn = (res.end + 1) >> PAGE_SHIFT;
 		if (end_pfn > pfn)
@@ -484,7 +484,7 @@ static int __is_ram(unsigned long pfn, unsigned long nr_pages, void *arg)
 }
 /*
  * This generic page_is_ram() returns true if specified address is
- * registered as "System RAM" in iomem_resource list.
+ * registered as System RAM in iomem_resource list.
  */
 int __weak page_is_ram(unsigned long pfn)
 {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

[Toshi Kani]

Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
instead of strcmp() with "System RAM", in the resource table.

No functional change is made to the interface.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/arm/plat-samsung/pm-check.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/pm-check.c b/arch/arm/plat-samsung/pm-check.c
index 04aff2c..70f2f69 100644
--- a/arch/arm/plat-samsung/pm-check.c
+++ b/arch/arm/plat-samsung/pm-check.c
@@ -53,8 +53,8 @@ static void s3c_pm_run_res(struct resource *ptr, run_fn_t fn, u32 *arg)
 		if (ptr->child != NULL)
 			s3c_pm_run_res(ptr->child, fn, arg);
 
-		if ((ptr->flags & IORESOURCE_MEM) &&
-		    strcmp(ptr->name, "System RAM") == 0) {
+		if ((ptr->flags & IORESOURCE_SYSTEM_RAM)
+				== IORESOURCE_SYSTEM_RAM) {
 			S3C_PMDBG("Found system RAM at %08lx..%08lx\n",
 				  (unsigned long)ptr->start,
 				  (unsigned long)ptr->end);

[PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

[Toshi Kani]

Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
instead of strcmp() with "System RAM", in the resource table.

No functional change is made to the interface.

Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 arch/arm/plat-samsung/pm-check.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-samsung/pm-check.c b/arch/arm/plat-samsung/pm-check.c
index 04aff2c..70f2f69 100644
--- a/arch/arm/plat-samsung/pm-check.c
+++ b/arch/arm/plat-samsung/pm-check.c
@@ -53,8 +53,8 @@ static void s3c_pm_run_res(struct resource *ptr, run_fn_t fn, u32 *arg)
 		if (ptr->child != NULL)
 			s3c_pm_run_res(ptr->child, fn, arg);
 
-		if ((ptr->flags & IORESOURCE_MEM) &&
-		    strcmp(ptr->name, "System RAM") == 0) {
+		if ((ptr->flags & IORESOURCE_SYSTEM_RAM)
+				== IORESOURCE_SYSTEM_RAM) {
 			S3C_PMDBG("Found system RAM at %08lx..%08lx\n",
 				  (unsigned long)ptr->start,
 				  (unsigned long)ptr->end);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 11/11] ACPI/EINJ: Allow memory error injection to NVDIMM

[Toshi Kani]

In the case of memory error injection, einj_error_inject() checks
if a target address is System RAM.  Change this check to allow
injecting a memory error to NVDIMM by calling region_intersects()
with "Persistent Memory".  This enables memory error testing on
both System RAM and NVDIMM.

In addition, page_is_ram() is replaced with region_intersects()
with IORESOURCE_SYSTEM_RAM, so that it can verify a target address
range with the requested size.

Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: linux-nvdimm@lists.01.org
Cc: linux-acpi@vger.kernel.org
Acked-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 drivers/acpi/apei/einj.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index 0431883..cad6fd7 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -519,7 +519,7 @@ static int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2,
 			     u64 param3, u64 param4)
 {
 	int rc;
-	unsigned long pfn;
+	u64 base_addr, size;
 
 	/* If user manually set "flags", make sure it is legal */
 	if (flags && (flags &
@@ -545,10 +545,17 @@ static int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2,
 	/*
 	 * Disallow crazy address masks that give BIOS leeway to pick
 	 * injection address almost anywhere. Insist on page or
-	 * better granularity and that target address is normal RAM.
+	 * better granularity and that target address is normal RAM or
+	 * NVDIMM.
 	 */
-	pfn = PFN_DOWN(param1 & param2);
-	if (!page_is_ram(pfn) || ((param2 & PAGE_MASK) != PAGE_MASK))
+	base_addr = param1 & param2;
+	size = ~param2 + 1;
+
+	if (((param2 & PAGE_MASK) != PAGE_MASK) ||
+	    ((region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM,
+				NULL) != REGION_INTERSECTS) &&
+	     (region_intersects(base_addr, size, IORESOURCE_MEM,
+				"Persistent Memory") != REGION_INTERSECTS)))
 		return -EINVAL;
 
 inject:

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 11/11] ACPI/EINJ: Allow memory error injection to NVDIMM

[Toshi Kani]

In the case of memory error injection, einj_error_inject() checks
if a target address is System RAM.  Change this check to allow
injecting a memory error to NVDIMM by calling region_intersects()
with "Persistent Memory".  This enables memory error testing on
both System RAM and NVDIMM.

In addition, page_is_ram() is replaced with region_intersects()
with IORESOURCE_SYSTEM_RAM, so that it can verify a target address
range with the requested size.

Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: linux-nvdimm@lists.01.org
Cc: linux-acpi@vger.kernel.org
Acked-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 drivers/acpi/apei/einj.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index 0431883..cad6fd7 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -519,7 +519,7 @@ static int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2,
 			     u64 param3, u64 param4)
 {
 	int rc;
-	unsigned long pfn;
+	u64 base_addr, size;
 
 	/* If user manually set "flags", make sure it is legal */
 	if (flags && (flags &
@@ -545,10 +545,17 @@ static int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2,
 	/*
 	 * Disallow crazy address masks that give BIOS leeway to pick
 	 * injection address almost anywhere. Insist on page or
-	 * better granularity and that target address is normal RAM.
+	 * better granularity and that target address is normal RAM or
+	 * NVDIMM.
 	 */
-	pfn = PFN_DOWN(param1 & param2);
-	if (!page_is_ram(pfn) || ((param2 & PAGE_MASK) != PAGE_MASK))
+	base_addr = param1 & param2;
+	size = ~param2 + 1;
+
+	if (((param2 & PAGE_MASK) != PAGE_MASK) ||
+	    ((region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM,
+				NULL) != REGION_INTERSECTS) &&
+	     (region_intersects(base_addr, size, IORESOURCE_MEM,
+				"Persistent Memory") != REGION_INTERSECTS)))
 		return -EINVAL;
 
 inject:

[PATCH 11/11] ACPI/EINJ: Allow memory error injection to NVDIMM

[Toshi Kani]

In the case of memory error injection, einj_error_inject() checks
if a target address is System RAM.  Change this check to allow
injecting a memory error to NVDIMM by calling region_intersects()
with "Persistent Memory".  This enables memory error testing on
both System RAM and NVDIMM.

In addition, page_is_ram() is replaced with region_intersects()
with IORESOURCE_SYSTEM_RAM, so that it can verify a target address
range with the requested size.

Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: linux-nvdimm@lists.01.org
Cc: linux-acpi@vger.kernel.org
Acked-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
---
 drivers/acpi/apei/einj.c |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index 0431883..cad6fd7 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -519,7 +519,7 @@ static int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2,
 			     u64 param3, u64 param4)
 {
 	int rc;
-	unsigned long pfn;
+	u64 base_addr, size;
 
 	/* If user manually set "flags", make sure it is legal */
 	if (flags && (flags &
@@ -545,10 +545,17 @@ static int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2,
 	/*
 	 * Disallow crazy address masks that give BIOS leeway to pick
 	 * injection address almost anywhere. Insist on page or
-	 * better granularity and that target address is normal RAM.
+	 * better granularity and that target address is normal RAM or
+	 * NVDIMM.
 	 */
-	pfn = PFN_DOWN(param1 & param2);
-	if (!page_is_ram(pfn) || ((param2 & PAGE_MASK) != PAGE_MASK))
+	base_addr = param1 & param2;
+	size = ~param2 + 1;
+
+	if (((param2 & PAGE_MASK) != PAGE_MASK) ||
+	    ((region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM,
+				NULL) != REGION_INTERSECTS) &&
+	     (region_intersects(base_addr, size, IORESOURCE_MEM,
+				"Persistent Memory") != REGION_INTERSECTS)))
 		return -EINVAL;
 
 inject:

Re: [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

[Krzysztof Kozlowski]

On 15.12.2015 08:37, Toshi Kani wrote:
> Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
> instead of strcmp() with "System RAM", in the resource table.
> 
> No functional change is made to the interface.
> 
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> ---
>  arch/arm/plat-samsung/pm-check.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

Re: [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() to use System RAM type

[Krzysztof Kozlowski]

On 15.12.2015 08:37, Toshi Kani wrote:
> Change s3c_pm_run_res() to check with IORESOURCE_SYSTEM_RAM,
> instead of strcmp() with "System RAM", in the resource table.
> 
> No functional change is made to the interface.
> 
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> ---
>  arch/arm/plat-samsung/pm-check.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote:
> I/O resource type, IORESOURCE_MEM, is used for all types of
> memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
> Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
> reserved, and so on.  This requires walk_system_ram_range(),
> walk_system_ram_res(), and region_intersects() to use strcmp()
> against string "System RAM" to search System RAM ranges in the
> iomem table, which is inefficient.  __ioremap_caller() and
> reserve_memtype() on x86, for instance, call walk_system_ram_range()
> for every request to check if a given range is in System RAM ranges.
> 
> However, adding a new I/O resource type for System RAM is not
> a viable option [1].

I think you should explain here why it isn't a viable option instead of
quoting some flaky reference which might or might not be there in the
future.

> Instead, this patch adds a new modifier
> flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
> extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].
> 
> To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
> work continuously for System RAM, resource_ext_type() is added
> for extracting extended type bit(s).
> 
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reference[1]: https://lkml.org/lkml/2015/12/3/540
> Reference[2]: https://lkml.org/lkml/2015/12/3/582

References should look something like this:

Link: http://lkml.kernel.org/r/<Message-ID>

> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> ---
>  include/linux/ioport.h |   11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 24bea08..4b65d94 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -49,12 +49,19 @@ struct resource {
>  #define IORESOURCE_WINDOW	0x00200000	/* forwarded by bridge */
>  #define IORESOURCE_MUXED	0x00400000	/* Resource is software muxed */
>  
> +#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource extended types */

Should this be 0x07000000 so that we make all there bits belong to the
extended types? Are we going to need so many?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote:
> I/O resource type, IORESOURCE_MEM, is used for all types of
> memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
> Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
> reserved, and so on.  This requires walk_system_ram_range(),
> walk_system_ram_res(), and region_intersects() to use strcmp()
> against string "System RAM" to search System RAM ranges in the
> iomem table, which is inefficient.  __ioremap_caller() and
> reserve_memtype() on x86, for instance, call walk_system_ram_range()
> for every request to check if a given range is in System RAM ranges.
> 
> However, adding a new I/O resource type for System RAM is not
> a viable option [1].

I think you should explain here why it isn't a viable option instead of
quoting some flaky reference which might or might not be there in the
future.

> Instead, this patch adds a new modifier
> flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
> extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].
> 
> To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
> work continuously for System RAM, resource_ext_type() is added
> for extracting extended type bit(s).
> 
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Reference[1]: https://lkml.org/lkml/2015/12/3/540
> Reference[2]: https://lkml.org/lkml/2015/12/3/582

References should look something like this:

Link: http://lkml.kernel.org/r/<Message-ID>

> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> ---
>  include/linux/ioport.h |   11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 24bea08..4b65d94 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -49,12 +49,19 @@ struct resource {
>  #define IORESOURCE_WINDOW	0x00200000	/* forwarded by bridge */
>  #define IORESOURCE_MUXED	0x00400000	/* Resource is software muxed */
>  
> +#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource extended types */

Should this be 0x07000000 so that we make all there bits belong to the
extended types? Are we going to need so many?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-16 at 13:26 +0100, Borislav Petkov wrote:
> On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote:
> > I/O resource type, IORESOURCE_MEM, is used for all types of
> > memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
> > Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
> > reserved, and so on.  This requires walk_system_ram_range(),
> > walk_system_ram_res(), and region_intersects() to use strcmp()
> > against string "System RAM" to search System RAM ranges in the
> > iomem table, which is inefficient.  __ioremap_caller() and
> > reserve_memtype() on x86, for instance, call walk_system_ram_range()
> > for every request to check if a given range is in System RAM ranges.
> > 
> > However, adding a new I/O resource type for System RAM is not
> > a viable option [1].
> 
> I think you should explain here why it isn't a viable option instead of
> quoting some flaky reference which might or might not be there in the
> future.

Agreed.  I will include summary of the descriptions here.

> > Instead, this patch adds a new modifier
> > flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
> > extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].
> > 
> > To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
> > work continuously for System RAM, resource_ext_type() is added
> > for extracting extended type bit(s).
> > 
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Reference[1]: https://lkml.org/lkml/2015/12/3/540
> > Reference[2]: https://lkml.org/lkml/2015/12/3/582
> 
> References should look something like this:
> 
> Link: http://lkml.kernel.org/r/<Message-ID>;

I see.  I will update per the format.

> > Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> > ---
> >  include/linux/ioport.h |   11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > index 24bea08..4b65d94 100644
> > --- a/include/linux/ioport.h
> > +++ b/include/linux/ioport.h
> > @@ -49,12 +49,19 @@ struct resource {
> >  #define IORESOURCE_WINDOW	0x00200000	/* forwarded by
> > bridge */
> >  #define IORESOURCE_MUXED	0x00400000	/* Resource is
> > software muxed */
> >  
> > +#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource
> > extended types */
> 
> Should this be 0x07000000 so that we make all there bits belong to the
> extended types? Are we going to need so many?

Besides "System RAM", which is commonly searched by multiple callers, we
only have a few other uncommon cases:
 - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
Storage".
 - kexec_file.c searches for "Crash kernel".
 - einj.c will search for "Persistent Memory".

This is because drivers typically know their ranges without searching
through the resource table.  So, it does not seem that we need to
preallocate the bits at this point.

Thanks,
-Toshi

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-16 at 13:26 +0100, Borislav Petkov wrote:
> On Mon, Dec 14, 2015 at 04:37:16PM -0700, Toshi Kani wrote:
> > I/O resource type, IORESOURCE_MEM, is used for all types of
> > memory-mapped ranges, ex. System RAM, System ROM, Video RAM,
> > Persistent Memory, PCI Bus, PCI MMCONFIG, ACPI Tables, IOAPIC,
> > reserved, and so on.  This requires walk_system_ram_range(),
> > walk_system_ram_res(), and region_intersects() to use strcmp()
> > against string "System RAM" to search System RAM ranges in the
> > iomem table, which is inefficient.  __ioremap_caller() and
> > reserve_memtype() on x86, for instance, call walk_system_ram_range()
> > for every request to check if a given range is in System RAM ranges.
> > 
> > However, adding a new I/O resource type for System RAM is not
> > a viable option [1].
> 
> I think you should explain here why it isn't a viable option instead of
> quoting some flaky reference which might or might not be there in the
> future.

Agreed.  I will include summary of the descriptions here.

> > Instead, this patch adds a new modifier
> > flag IORESOURCE_SYSRAM to IORESOURCE_MEM, which introduces an
> > extended I/O resource type, IORESOURCE_SYSTEM_RAM [2].
> > 
> > To keep the code 'if (resource_type(r) == IORESOURCE_MEM)' to
> > work continuously for System RAM, resource_ext_type() is added
> > for extracting extended type bit(s).
> > 
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Reference[1]: https://lkml.org/lkml/2015/12/3/540
> > Reference[2]: https://lkml.org/lkml/2015/12/3/582
> 
> References should look something like this:
> 
> Link: http://lkml.kernel.org/r/<Message-ID>;

I see.  I will update per the format.

> > Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> > ---
> >  include/linux/ioport.h |   11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > index 24bea08..4b65d94 100644
> > --- a/include/linux/ioport.h
> > +++ b/include/linux/ioport.h
> > @@ -49,12 +49,19 @@ struct resource {
> >  #define IORESOURCE_WINDOW	0x00200000	/* forwarded by
> > bridge */
> >  #define IORESOURCE_MUXED	0x00400000	/* Resource is
> > software muxed */
> >  
> > +#define IORESOURCE_EXT_TYPE_BITS 0x01000000	/* Resource
> > extended types */
> 
> Should this be 0x07000000 so that we make all there bits belong to the
> extended types? Are we going to need so many?

Besides "System RAM", which is commonly searched by multiple callers, we
only have a few other uncommon cases:
 - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
Storage".
 - kexec_file.c searches for "Crash kernel".
 - einj.c will search for "Persistent Memory".

This is because drivers typically know their ranges without searching
through the resource table.  So, it does not seem that we need to
preallocate the bits at this point.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote:
> Besides "System RAM", which is commonly searched by multiple callers, we
> only have a few other uncommon cases:
>  - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
> Storage".
>  - kexec_file.c searches for "Crash kernel".
>  - einj.c will search for "Persistent Memory".

Right, about those other types: your patchset improves the situation
but doesn't really get rid of the strcmp() and the strings. And using
strings to find resource types still looks yucky to me, even a week
later. :)

So how hard is it to do:

	region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM);
	region_intersects(base_addr, size, IORESOURCE_MEM, RES_TYPE_PERSISTENT);
	walk_iomem_res(RES_TYPE_GART, IORESOURCE_MEM, 0, -1, ced, get_gart_ranges_callback);
	...

and so on instead of using those silly strings?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote:
> Besides "System RAM", which is commonly searched by multiple callers, we
> only have a few other uncommon cases:
>  - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
> Storage".
>  - kexec_file.c searches for "Crash kernel".
>  - einj.c will search for "Persistent Memory".

Right, about those other types: your patchset improves the situation
but doesn't really get rid of the strcmp() and the strings. And using
strings to find resource types still looks yucky to me, even a week
later. :)

So how hard is it to do:

	region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM);
	region_intersects(base_addr, size, IORESOURCE_MEM, RES_TYPE_PERSISTENT);
	walk_iomem_res(RES_TYPE_GART, IORESOURCE_MEM, 0, -1, ced, get_gart_ranges_callback);
	...

and so on instead of using those silly strings?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-16 at 16:49 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote:
> > Besides "System RAM", which is commonly searched by multiple callers,
> > we
> > only have a few other uncommon cases:
> >  - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
> > Storage".
> >  - kexec_file.c searches for "Crash kernel".
> >  - einj.c will search for "Persistent Memory".
> 
> Right, about those other types: your patchset improves the situation
> but doesn't really get rid of the strcmp() and the strings. And using
> strings to find resource types still looks yucky to me, even a week
> later. :)
> 
> So how hard is it to do:
> 
> 	region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM);
> 	region_intersects(base_addr, size, IORESOURCE_MEM,
> RES_TYPE_PERSISTENT);
> 	walk_iomem_res(RES_TYPE_GART, IORESOURCE_MEM, 0, -1, ced,
> get_gart_ranges_callback);
> 	...
> 
> and so on instead of using those silly strings?

We do not have enough bits left to cover any potential future use-cases
with other strings if we are going to get rid of strcmp() completely. 
 Since the searches from crash and kexec are one-time thing, and einj is a
R&D tool, I think we can leave the strcmp() check for these special cases,
and keep the interface flexible with any strings.

Thanks,
-Toshi

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-16 at 16:49 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 08:44:02AM -0700, Toshi Kani wrote:
> > Besides "System RAM", which is commonly searched by multiple callers,
> > we
> > only have a few other uncommon cases:
> >  - crash.c searches for "GART", "ACPI Tables", and "ACPI Non-volatile
> > Storage".
> >  - kexec_file.c searches for "Crash kernel".
> >  - einj.c will search for "Persistent Memory".
> 
> Right, about those other types: your patchset improves the situation
> but doesn't really get rid of the strcmp() and the strings. And using
> strings to find resource types still looks yucky to me, even a week
> later. :)
> 
> So how hard is it to do:
> 
> 	region_intersects(base_addr, size, IORESOURCE_SYSTEM_RAM);
> 	region_intersects(base_addr, size, IORESOURCE_MEM,
> RES_TYPE_PERSISTENT);
> 	walk_iomem_res(RES_TYPE_GART, IORESOURCE_MEM, 0, -1, ced,
> get_gart_ranges_callback);
> 	...
> 
> and so on instead of using those silly strings?

We do not have enough bits left to cover any potential future use-cases
with other strings if we are going to get rid of strcmp() completely. 
 Since the searches from crash and kexec are one-time thing, and einj is a
R&D tool, I think we can leave the strcmp() check for these special cases,
and keep the interface flexible with any strings.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote:
> We do not have enough bits left to cover any potential future use-cases
> with other strings if we are going to get rid of strcmp() completely.

Look at the examples I gave. I'm talking about having an additional
identifier which can be a number and not a bit.

>  Since the searches from crash and kexec are one-time thing, and einj
> is a R&D tool, I think we can leave the strcmp() check for these
> special cases, and keep the interface flexible with any strings.

I don't think using strings is anywhere close to flexible. If at all, it
is an odd use case which shouldnt've been allowed in in the first place.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote:
> We do not have enough bits left to cover any potential future use-cases
> with other strings if we are going to get rid of strcmp() completely.

Look at the examples I gave. I'm talking about having an additional
identifier which can be a number and not a bit.

>  Since the searches from crash and kexec are one-time thing, and einj
> is a R&D tool, I think we can leave the strcmp() check for these
> special cases, and keep the interface flexible with any strings.

I don't think using strings is anywhere close to flexible. If at all, it
is an odd use case which shouldnt've been allowed in in the first place.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Dan Williams]

On Wed, Dec 16, 2015 at 9:45 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote:
>> We do not have enough bits left to cover any potential future use-cases
>> with other strings if we are going to get rid of strcmp() completely.
>
> Look at the examples I gave. I'm talking about having an additional
> identifier which can be a number and not a bit.
>
>>  Since the searches from crash and kexec are one-time thing, and einj
>> is a R&D tool, I think we can leave the strcmp() check for these
>> special cases, and keep the interface flexible with any strings.
>
> I don't think using strings is anywhere close to flexible. If at all, it
> is an odd use case which shouldnt've been allowed in in the first place.
>

It's possible that as far as the resource table is concerned the
resource type might just be "reserved".  It may not be until after a
driver loads that we discover the memory range type.  The identifying
string is driver specific at that point.

All this to say that with strcmp we can search for any custom type .
Otherwise I think we're looking at updating the request_region()
interface to take a type parameter.  That makes strcmp capability more
attractive compared to updating a potentially large number of
request_region() call sites.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Dan Williams]

On Wed, Dec 16, 2015 at 9:45 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote:
>> We do not have enough bits left to cover any potential future use-cases
>> with other strings if we are going to get rid of strcmp() completely.
>
> Look at the examples I gave. I'm talking about having an additional
> identifier which can be a number and not a bit.
>
>>  Since the searches from crash and kexec are one-time thing, and einj
>> is a R&D tool, I think we can leave the strcmp() check for these
>> special cases, and keep the interface flexible with any strings.
>
> I don't think using strings is anywhere close to flexible. If at all, it
> is an odd use case which shouldnt've been allowed in in the first place.
>

It's possible that as far as the resource table is concerned the
resource type might just be "reserved".  It may not be until after a
driver loads that we discover the memory range type.  The identifying
string is driver specific at that point.

All this to say that with strcmp we can search for any custom type .
Otherwise I think we're looking at updating the request_region()
interface to take a type parameter.  That makes strcmp capability more
attractive compared to updating a potentially large number of
request_region() call sites.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
> It's possible that as far as the resource table is concerned the
> resource type might just be "reserved".  It may not be until after a
> driver loads that we discover the memory range type.  The identifying
> string is driver specific at that point.

So how many types are we talking about here? Because I don't find a whole lot:

$ git grep -E "(walk_iomem_res|find_next_iomem_res|region_intersects)" -- *.c | grep -Eo '\".*\"'
"GART"
"ACPI Tables"
"ACPI Non-volatile Storage"
"Crash kernel"
"System RAM"
"System RAM"
"System RAM"

An int type could contain 2^32 different types.

> All this to say that with strcmp we can search for any custom type .
> Otherwise I think we're looking at updating the request_region()
> interface to take a type parameter.  That makes strcmp capability more
> attractive compared to updating a potentially large number of
> request_region() call sites.

Right, but I don't think that @name param to request_region() was ever
meant to be mis-used as a matching attribute when iterating over the
resource types.

Now, imagine you have to do this pretty often. Which is faster: a
strcmp() or an int comparison...?

Even if this cannot be changed easily/in one go, maybe we should at
least think about starting doing it right so that the strcmp() "fun" is
phased out gradually...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
> It's possible that as far as the resource table is concerned the
> resource type might just be "reserved".  It may not be until after a
> driver loads that we discover the memory range type.  The identifying
> string is driver specific at that point.

So how many types are we talking about here? Because I don't find a whole lot:

$ git grep -E "(walk_iomem_res|find_next_iomem_res|region_intersects)" -- *.c | grep -Eo '\".*\"'
"GART"
"ACPI Tables"
"ACPI Non-volatile Storage"
"Crash kernel"
"System RAM"
"System RAM"
"System RAM"

An int type could contain 2^32 different types.

> All this to say that with strcmp we can search for any custom type .
> Otherwise I think we're looking at updating the request_region()
> interface to take a type parameter.  That makes strcmp capability more
> attractive compared to updating a potentially large number of
> request_region() call sites.

Right, but I don't think that @name param to request_region() was ever
meant to be mis-used as a matching attribute when iterating over the
resource types.

Now, imagine you have to do this pretty often. Which is faster: a
strcmp() or an int comparison...?

Even if this cannot be changed easily/in one go, maybe we should at
least think about starting doing it right so that the strcmp() "fun" is
phased out gradually...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Dan Williams]

On Wed, Dec 16, 2015 at 10:17 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
[..]
> Now, imagine you have to do this pretty often. Which is faster: a
> strcmp() or an int comparison...?

Aside from "System RAM" checks I don't think any of these strcmp
usages are in fast paths.

> Even if this cannot be changed easily/in one go, maybe we should at
> least think about starting doing it right so that the strcmp() "fun" is
> phased out gradually...

Sure, but I really don't find use of strcmp() that onerous in slow paths.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Dan Williams]

On Wed, Dec 16, 2015 at 10:17 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
[..]
> Now, imagine you have to do this pretty often. Which is faster: a
> strcmp() or an int comparison...?

Aside from "System RAM" checks I don't think any of these strcmp
usages are in fast paths.

> Even if this cannot be changed easily/in one go, maybe we should at
> least think about starting doing it right so that the strcmp() "fun" is
> phased out gradually...

Sure, but I really don't find use of strcmp() that onerous in slow paths.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 10:57:52AM -0800, Dan Williams wrote:
> Aside from "System RAM" checks I don't think any of these strcmp
> usages are in fast paths.

Sure, 0.1% slowdown here, 0.2% slowdown there... this is how you get a
bloated kernel.

In addition to that, using strings to identify resources is ugly. "It
was there so we used it" is not an excuse.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 10:57:52AM -0800, Dan Williams wrote:
> Aside from "System RAM" checks I don't think any of these strcmp
> usages are in fast paths.

Sure, 0.1% slowdown here, 0.2% slowdown there... this is how you get a
bloated kernel.

In addition to that, using strings to identify resources is ugly. "It
was there so we used it" is not an excuse.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-16 at 19:17 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
> > It's possible that as far as the resource table is concerned the
> > resource type might just be "reserved".  It may not be until after a
> > driver loads that we discover the memory range type.  The identifying
> > string is driver specific at that point.
> 
> So how many types are we talking about here? Because I don't find a whole
> lot:
> 
> $ git grep -E "(walk_iomem_res|find_next_iomem_res|region_intersects)" --
> *.c | grep -Eo '\".*\"'
> "GART"
> "ACPI Tables"
> "ACPI Non-volatile Storage"
> "Crash kernel"
> "System RAM"
> "System RAM"
> "System RAM"
> 
> An int type could contain 2^32 different types.

In this approach, as I understand, we add a new field to 'struct resource',
i.e. 'type' in this example.

 struct resource crashk_res = {
        .name  = "Crash kernel",
        .start = 0,
        .end   = 0,
        .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+ 	.type  = RES_TYPE_CRASH_KERNEL,
 };

And we change the callers, such as "kernel/kexec_file.c" to search with
this RES_TYPE.

 ret = walk_iomem_res(RES_TYPE_CRASH_KERNEL,
		IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, ...);

We only change the resource entries that support the search interfaces to:
 - Assign RES_TYPE_XXX.
 - Initialize 'type' in its 'struct resource' with the type.

This avoids changing all drivers.  When we have a new search for "foo", we
will then need to:
 - Define RES_TYPE_FOO.
 - Add '.type = RES_TYPE_FOO' to the code where it initializes the "foo"
entry.

This scheme may have a problem, though.  For instance, when someone writes
a loadable module that searches for "foo", but the "foo" entry may be
initialized in a distro kernel/driver that cannot be modified.  Since this
search is only necessary to obtain a range initialized by other module,
this scenario is likely to happen.  We no longer have ability to search for
a new entry unless we modify the code that initializes the entry first.

> > All this to say that with strcmp we can search for any custom type .
> > Otherwise I think we're looking at updating the request_region()
> > interface to take a type parameter.  That makes strcmp capability more
> > attractive compared to updating a potentially large number of
> > request_region() call sites.
> 
> Right, but I don't think that @name param to request_region() was ever
> meant to be mis-used as a matching attribute when iterating over the
> resource types.

Even if we avoid strcmp() with @name in the kernel, user applications will
continue to use @name since that is the only type available in /proc/iomem.
 For instance, kexec has its own search function with a string name.

 https://github.com/Tasssadar/kexec-tools/blob/master/kexec/kexec-iomem.c

> Now, imagine you have to do this pretty often. Which is faster: a
> strcmp() or an int comparison...?
> 
> Even if this cannot be changed easily/in one go, maybe we should at
> least think about starting doing it right so that the strcmp() "fun" is
> phased out gradually...

When a new commonly-used search name comes up, we can define it as a new
extended I/O resource type similar to IORESOURCE_SYSTEM_RAM.  For the
current remaining cases, i.e. crash, kexec, and einj, they have no impact
to performance.  Leaving these special cases aside will keep the ability to
search for any entry without changing the kernel, and save some memory
space from adding the new 'type'.

Thanks,
-Toshi

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-16 at 19:17 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 09:52:37AM -0800, Dan Williams wrote:
> > It's possible that as far as the resource table is concerned the
> > resource type might just be "reserved".  It may not be until after a
> > driver loads that we discover the memory range type.  The identifying
> > string is driver specific at that point.
> 
> So how many types are we talking about here? Because I don't find a whole
> lot:
> 
> $ git grep -E "(walk_iomem_res|find_next_iomem_res|region_intersects)" --
> *.c | grep -Eo '\".*\"'
> "GART"
> "ACPI Tables"
> "ACPI Non-volatile Storage"
> "Crash kernel"
> "System RAM"
> "System RAM"
> "System RAM"
> 
> An int type could contain 2^32 different types.

In this approach, as I understand, we add a new field to 'struct resource',
i.e. 'type' in this example.

 struct resource crashk_res = {
        .name  = "Crash kernel",
        .start = 0,
        .end   = 0,
        .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+ 	.type  = RES_TYPE_CRASH_KERNEL,
 };

And we change the callers, such as "kernel/kexec_file.c" to search with
this RES_TYPE.

 ret = walk_iomem_res(RES_TYPE_CRASH_KERNEL,
		IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, ...);

We only change the resource entries that support the search interfaces to:
 - Assign RES_TYPE_XXX.
 - Initialize 'type' in its 'struct resource' with the type.

This avoids changing all drivers.  When we have a new search for "foo", we
will then need to:
 - Define RES_TYPE_FOO.
 - Add '.type = RES_TYPE_FOO' to the code where it initializes the "foo"
entry.

This scheme may have a problem, though.  For instance, when someone writes
a loadable module that searches for "foo", but the "foo" entry may be
initialized in a distro kernel/driver that cannot be modified.  Since this
search is only necessary to obtain a range initialized by other module,
this scenario is likely to happen.  We no longer have ability to search for
a new entry unless we modify the code that initializes the entry first.

> > All this to say that with strcmp we can search for any custom type .
> > Otherwise I think we're looking at updating the request_region()
> > interface to take a type parameter.  That makes strcmp capability more
> > attractive compared to updating a potentially large number of
> > request_region() call sites.
> 
> Right, but I don't think that @name param to request_region() was ever
> meant to be mis-used as a matching attribute when iterating over the
> resource types.

Even if we avoid strcmp() with @name in the kernel, user applications will
continue to use @name since that is the only type available in /proc/iomem.
 For instance, kexec has its own search function with a string name.

 https://github.com/Tasssadar/kexec-tools/blob/master/kexec/kexec-iomem.c

> Now, imagine you have to do this pretty often. Which is faster: a
> strcmp() or an int comparison...?
> 
> Even if this cannot be changed easily/in one go, maybe we should at
> least think about starting doing it right so that the strcmp() "fun" is
> phased out gradually...

When a new commonly-used search name comes up, we can define it as a new
extended I/O resource type similar to IORESOURCE_SYSTEM_RAM.  For the
current remaining cases, i.e. crash, kexec, and einj, they have no impact
to performance.  Leaving these special cases aside will keep the ability to
search for any entry without changing the kernel, and save some memory
space from adding the new 'type'.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote:
> This scheme may have a problem, though.  For instance, when someone writes
> a loadable module that searches for "foo", but the "foo" entry may be
> initialized in a distro kernel/driver that cannot be modified.  Since this
> search is only necessary to obtain a range initialized by other module,
> this scenario is likely to happen.  We no longer have ability to search for
> a new entry unless we modify the code that initializes the entry first.

Since when do we pay attention to out-of-tree modules which cannot be
changed?

Regardless, we don't necessarily need to change the callers - we could
add new ones of the form walk_iomem_resource_by_type() or whatever its
name is going to be which uses the ->type attribute of the resource and
phase out the old ones slowly. New code will call the better interfaces,
we should probably even add a checkpatch rule to check for that.

> Even if we avoid strcmp() with @name in the kernel, user applications will
> continue to use @name since that is the only type available in /proc/iomem.
>  For instance, kexec has its own search function with a string name.

See above.

> When a new commonly-used search name comes up, we can define it as a new
> extended I/O resource type similar to IORESOURCE_SYSTEM_RAM.  For the
> current remaining cases, i.e. crash, kexec, and einj, they have no impact
> to performance.  Leaving these special cases aside will keep the ability to
> search for any entry without changing the kernel, and save some memory
> space from adding the new 'type'.

Again, we can leave the old interfaces at peace but going forward, we
should make the searching for resources saner and stop using silly
strings.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote:
> This scheme may have a problem, though.  For instance, when someone writes
> a loadable module that searches for "foo", but the "foo" entry may be
> initialized in a distro kernel/driver that cannot be modified.  Since this
> search is only necessary to obtain a range initialized by other module,
> this scenario is likely to happen.  We no longer have ability to search for
> a new entry unless we modify the code that initializes the entry first.

Since when do we pay attention to out-of-tree modules which cannot be
changed?

Regardless, we don't necessarily need to change the callers - we could
add new ones of the form walk_iomem_resource_by_type() or whatever its
name is going to be which uses the ->type attribute of the resource and
phase out the old ones slowly. New code will call the better interfaces,
we should probably even add a checkpatch rule to check for that.

> Even if we avoid strcmp() with @name in the kernel, user applications will
> continue to use @name since that is the only type available in /proc/iomem.
>  For instance, kexec has its own search function with a string name.

See above.

> When a new commonly-used search name comes up, we can define it as a new
> extended I/O resource type similar to IORESOURCE_SYSTEM_RAM.  For the
> current remaining cases, i.e. crash, kexec, and einj, they have no impact
> to performance.  Leaving these special cases aside will keep the ability to
> search for any entry without changing the kernel, and save some memory
> space from adding the new 'type'.

Again, we can leave the old interfaces at peace but going forward, we
should make the searching for resources saner and stop using silly
strings.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Tue, 2015-12-22 at 12:34 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote:
> > This scheme may have a problem, though.  For instance, when someone 
> > writes a loadable module that searches for "foo", but the "foo" entry 
> > may be initialized in a distro kernel/driver that cannot be modified. 
> >  Since this search is only necessary to obtain a range initialized by 
> > other module, this scenario is likely to happen.  We no longer have 
> > ability to search for a new entry unless we modify the code that
> > initializes the entry first.
> 
> Since when do we pay attention to out-of-tree modules which cannot be
> changed?

The above example referred the case with distros, not with the upstream. 
 That is, one writes a new loadable module and makes it available in the
upstream.  Then s/he makes it work on a distro used by the customers, but
may or may not be able to change the distro kernel/drivers used by the
customers.

> Regardless, we don't necessarily need to change the callers - we could
> add new ones of the form walk_iomem_resource_by_type() or whatever its
> name is going to be which uses the ->type attribute of the resource and
> phase out the old ones slowly. New code will call the better interfaces,
> we should probably even add a checkpatch rule to check for that.

I agree that we can add new interfaces with the type check.  This 'type'
may need some clarification since it is an assigned type, which is
different from I/O resource type.  That is, "System RAM" is an I/O resource
type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an assigned type
to a particular range of System RAM.  A range may be associated with
multiple names, so as multiple assigned types.  For lack of a better idea,
I may call it 'assign_type'.  I am open for a better name.

> > Even if we avoid strcmp() with @name in the kernel, user applications
> > will continue to use @name since that is the only type available in
> > /proc/iomem.  For instance, kexec has its own search function with a
> > string name.
> 
> See above.
> 
> > When a new commonly-used search name comes up, we can define it as a 
> > new extended I/O resource type similar to IORESOURCE_SYSTEM_RAM.  For 
> > the current remaining cases, i.e. crash, kexec, and einj, they have no
> > impact to performance.  Leaving these special cases aside will keep the
> > ability to search for any entry without changing the kernel, and save 
> > some memory space from adding the new 'type'.
> 
> Again, we can leave the old interfaces at peace but going forward, we
> should make the searching for resources saner and stop using silly
> strings.

OK, I will try to convert the existing callers with the new interfaces.

Thanks,
-Toshi

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Tue, 2015-12-22 at 12:34 +0100, Borislav Petkov wrote:
> On Wed, Dec 16, 2015 at 02:52:38PM -0700, Toshi Kani wrote:
> > This scheme may have a problem, though.  For instance, when someone 
> > writes a loadable module that searches for "foo", but the "foo" entry 
> > may be initialized in a distro kernel/driver that cannot be modified. 
> >  Since this search is only necessary to obtain a range initialized by 
> > other module, this scenario is likely to happen.  We no longer have 
> > ability to search for a new entry unless we modify the code that
> > initializes the entry first.
> 
> Since when do we pay attention to out-of-tree modules which cannot be
> changed?

The above example referred the case with distros, not with the upstream. 
 That is, one writes a new loadable module and makes it available in the
upstream.  Then s/he makes it work on a distro used by the customers, but
may or may not be able to change the distro kernel/drivers used by the
customers.

> Regardless, we don't necessarily need to change the callers - we could
> add new ones of the form walk_iomem_resource_by_type() or whatever its
> name is going to be which uses the ->type attribute of the resource and
> phase out the old ones slowly. New code will call the better interfaces,
> we should probably even add a checkpatch rule to check for that.

I agree that we can add new interfaces with the type check.  This 'type'
may need some clarification since it is an assigned type, which is
different from I/O resource type.  That is, "System RAM" is an I/O resource
type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an assigned type
to a particular range of System RAM.  A range may be associated with
multiple names, so as multiple assigned types.  For lack of a better idea,
I may call it 'assign_type'.  I am open for a better name.

> > Even if we avoid strcmp() with @name in the kernel, user applications
> > will continue to use @name since that is the only type available in
> > /proc/iomem.  For instance, kexec has its own search function with a
> > string name.
> 
> See above.
> 
> > When a new commonly-used search name comes up, we can define it as a 
> > new extended I/O resource type similar to IORESOURCE_SYSTEM_RAM.  For 
> > the current remaining cases, i.e. crash, kexec, and einj, they have no
> > impact to performance.  Leaving these special cases aside will keep the
> > ability to search for any entry without changing the kernel, and save 
> > some memory space from adding the new 'type'.
> 
> Again, we can leave the old interfaces at peace but going forward, we
> should make the searching for resources saner and stop using silly
> strings.

OK, I will try to convert the existing callers with the new interfaces.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote:
> The above example referred the case with distros, not with the upstream. 
>  That is, one writes a new loadable module and makes it available in the
> upstream.  Then s/he makes it work on a distro used by the customers, but
> may or may not be able to change the distro kernel/drivers used by the
> customers.

Huh?

Still sounds bogus to me. Distro kernels get stuff backported to them
all the time to accomodate new features, hw support.

Your new interfaces will be used only in new code so if distros want
it, they can either backport the new kernel interfaces or use an older
version with the strings.

> I agree that we can add new interfaces with the type check.  This 'type'
> may need some clarification since it is an assigned type, which is
> different from I/O resource type.  That is, "System RAM" is an I/O resource
> type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an assigned type
> to a particular range of System RAM.  A range may be associated with
> multiple names, so as multiple assigned types.  For lack of a better idea,
> I may call it 'assign_type'.  I am open for a better name.

Or assigned_type or named_type or so...

I think we should avoid calling it "type" completely in order to avoid
confusion with the IORESOURCE_* types and call it "desc" or so to mean
description, sort, etc, because the name is also a description of the
resource to a certain degree...

> OK, I will try to convert the existing callers with the new interfaces.

Either that or add the new interfaces, use them in your use case, add
big fat comments explaining that people should use those from now on
when searching by name and add a check to checkpatch to catch future
mis-uses...

Thanks!

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote:
> The above example referred the case with distros, not with the upstream. 
>  That is, one writes a new loadable module and makes it available in the
> upstream.  Then s/he makes it work on a distro used by the customers, but
> may or may not be able to change the distro kernel/drivers used by the
> customers.

Huh?

Still sounds bogus to me. Distro kernels get stuff backported to them
all the time to accomodate new features, hw support.

Your new interfaces will be used only in new code so if distros want
it, they can either backport the new kernel interfaces or use an older
version with the strings.

> I agree that we can add new interfaces with the type check.  This 'type'
> may need some clarification since it is an assigned type, which is
> different from I/O resource type.  That is, "System RAM" is an I/O resource
> type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an assigned type
> to a particular range of System RAM.  A range may be associated with
> multiple names, so as multiple assigned types.  For lack of a better idea,
> I may call it 'assign_type'.  I am open for a better name.

Or assigned_type or named_type or so...

I think we should avoid calling it "type" completely in order to avoid
confusion with the IORESOURCE_* types and call it "desc" or so to mean
description, sort, etc, because the name is also a description of the
resource to a certain degree...

> OK, I will try to convert the existing callers with the new interfaces.

Either that or add the new interfaces, use them in your use case, add
big fat comments explaining that people should use those from now on
when searching by name and add a check to checkpatch to catch future
mis-uses...

Thanks!

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote:
> On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote:
 :
> > I agree that we can add new interfaces with the type check.  This
> > 'type'
> > may need some clarification since it is an assigned type, which is
> > different from I/O resource type.  That is, "System RAM" is an I/O 
> > resource type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an 
> > assigned type to a particular range of System RAM.  A range may be 
> > associated with multiple names, so as multiple assigned types.  For 
> > lack of a better idea, I may call it 'assign_type'.  I am open for a
> > better name.
> 
> Or assigned_type or named_type or so...
> 
> I think we should avoid calling it "type" completely in order to avoid
> confusion with the IORESOURCE_* types and call it "desc" or so to mean
> description, sort, etc, because the name is also a description of the
> resource to a certain degree...

Agreed. I will use 'desc'.

> > OK, I will try to convert the existing callers with the new interfaces.
> 
> Either that or add the new interfaces, use them in your use case, add
> big fat comments explaining that people should use those from now on
> when searching by name and add a check to checkpatch to catch future
> mis-uses...

Sounds good.  I will look into it.

Thanks,
-Toshi

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote:
> On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote:
 :
> > I agree that we can add new interfaces with the type check.  This
> > 'type'
> > may need some clarification since it is an assigned type, which is
> > different from I/O resource type.  That is, "System RAM" is an I/O 
> > resource type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an 
> > assigned type to a particular range of System RAM.  A range may be 
> > associated with multiple names, so as multiple assigned types.  For 
> > lack of a better idea, I may call it 'assign_type'.  I am open for a
> > better name.
> 
> Or assigned_type or named_type or so...
> 
> I think we should avoid calling it "type" completely in order to avoid
> confusion with the IORESOURCE_* types and call it "desc" or so to mean
> description, sort, etc, because the name is also a description of the
> resource to a certain degree...

Agreed. I will use 'desc'.

> > OK, I will try to convert the existing callers with the new interfaces.
> 
> Either that or add the new interfaces, use them in your use case, add
> big fat comments explaining that people should use those from now on
> when searching by name and add a check to checkpatch to catch future
> mis-uses...

Sounds good.  I will look into it.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-23 at 19:23 -0700, Toshi Kani wrote:
> On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote:
> > On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote:
>  :
> > > I agree that we can add new interfaces with the type check.  This
> > > 'type'
> > > may need some clarification since it is an assigned type, which is
> > > different from I/O resource type.  That is, "System RAM" is an I/O 
> > > resource type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an 
> > > assigned type to a particular range of System RAM.  A range may be 
> > > associated with multiple names, so as multiple assigned types.  For 
> > > lack of a better idea, I may call it 'assign_type'.  I am open for a
> > > better name.
> > 
> > Or assigned_type or named_type or so...
> > 
> > I think we should avoid calling it "type" completely in order to avoid
> > confusion with the IORESOURCE_* types and call it "desc" or so to mean
> > description, sort, etc, because the name is also a description of the
> > resource to a certain degree...
> 
> Agreed. I will use 'desc'.
> 
> > > OK, I will try to convert the existing callers with the new
> > > interfaces.
> > 
> > Either that or add the new interfaces, use them in your use case, add
> > big fat comments explaining that people should use those from now on
> > when searching by name and add a check to checkpatch to catch future
> > mis-uses...
> 
> Sounds good.  I will look into it.

As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature
-removal.txt" file, and checkpatch removed this check in commit
78e3f1f01d2.  checkpatch does not have such check since then.  So, I am
inclined not to add this check back to checkpatch.

Thanks,
-Toshi

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Wed, 2015-12-23 at 19:23 -0700, Toshi Kani wrote:
> On Wed, 2015-12-23 at 15:23 +0100, Borislav Petkov wrote:
> > On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote:
>  :
> > > I agree that we can add new interfaces with the type check.  This
> > > 'type'
> > > may need some clarification since it is an assigned type, which is
> > > different from I/O resource type.  That is, "System RAM" is an I/O 
> > > resource type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an 
> > > assigned type to a particular range of System RAM.  A range may be 
> > > associated with multiple names, so as multiple assigned types.  For 
> > > lack of a better idea, I may call it 'assign_type'.  I am open for a
> > > better name.
> > 
> > Or assigned_type or named_type or so...
> > 
> > I think we should avoid calling it "type" completely in order to avoid
> > confusion with the IORESOURCE_* types and call it "desc" or so to mean
> > description, sort, etc, because the name is also a description of the
> > resource to a certain degree...
> 
> Agreed. I will use 'desc'.
> 
> > > OK, I will try to convert the existing callers with the new
> > > interfaces.
> > 
> > Either that or add the new interfaces, use them in your use case, add
> > big fat comments explaining that people should use those from now on
> > when searching by name and add a check to checkpatch to catch future
> > mis-uses...
> 
> Sounds good.  I will look into it.

As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature
-removal.txt" file, and checkpatch removed this check in commit
78e3f1f01d2.  checkpatch does not have such check since then.  So, I am
inclined not to add this check back to checkpatch.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Thu, Dec 24, 2015 at 10:08:57AM -0700, Toshi Kani wrote:
> As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature
> -removal.txt" file, and checkpatch removed this check in commit
> 78e3f1f01d2.  checkpatch does not have such check since then.  So, I am
> inclined not to add this check back to checkpatch.

I didn't mean that.

Rather, something along the lines of, for example,
the DEFINE_PCI_DEVICE_TABLE matching but match those
resource matching functions using the strings, i.e.,
"(walk_iomem_res|find_next_iomem_res|region_intersects)" or so and
warn when new code uses them and that it should rather use the new
desc-matching variants.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

Re: [PATCH 01/11] resource: Add System RAM resource type

[Borislav Petkov]

On Thu, Dec 24, 2015 at 10:08:57AM -0700, Toshi Kani wrote:
> As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature
> -removal.txt" file, and checkpatch removed this check in commit
> 78e3f1f01d2.  checkpatch does not have such check since then.  So, I am
> inclined not to add this check back to checkpatch.

I didn't mean that.

Rather, something along the lines of, for example,
the DEFINE_PCI_DEVICE_TABLE matching but match those
resource matching functions using the strings, i.e.,
"(walk_iomem_res|find_next_iomem_res|region_intersects)" or so and
warn when new code uses them and that it should rather use the new
desc-matching variants.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Thu, 2015-12-24 at 20:58 +0100, Borislav Petkov wrote:
> On Thu, Dec 24, 2015 at 10:08:57AM -0700, Toshi Kani wrote:
> > As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature
> > -removal.txt" file, and checkpatch removed this check in commit
> > 78e3f1f01d2.  checkpatch does not have such check since then.  So, I am
> > inclined not to add this check back to checkpatch.
> 
> I didn't mean that.
> 
> Rather, something along the lines of, for example,
> the DEFINE_PCI_DEVICE_TABLE matching but match those
> resource matching functions using the strings, i.e.,
> "(walk_iomem_res|find_next_iomem_res|region_intersects)" or so and
> warn when new code uses them and that it should rather use the new
> desc-matching variants.

OK, I will add a check to walk_iomem_res().  I will remove @name from
region_intersects(), and find_next_iomem_res() is an internal function.

Thanks,
-Toshi

Re: [PATCH 01/11] resource: Add System RAM resource type

[Toshi Kani]

On Thu, 2015-12-24 at 20:58 +0100, Borislav Petkov wrote:
> On Thu, Dec 24, 2015 at 10:08:57AM -0700, Toshi Kani wrote:
> > As for checkpatch, I noticed that commit 9c0ece069b3 removed "feature
> > -removal.txt" file, and checkpatch removed this check in commit
> > 78e3f1f01d2.  checkpatch does not have such check since then.  So, I am
> > inclined not to add this check back to checkpatch.
> 
> I didn't mean that.
> 
> Rather, something along the lines of, for example,
> the DEFINE_PCI_DEVICE_TABLE matching but match those
> resource matching functions using the strings, i.e.,
> "(walk_iomem_res|find_next_iomem_res|region_intersects)" or so and
> warn when new code uses them and that it should rather use the new
> desc-matching variants.

OK, I will add a check to walk_iomem_res().  I will remove @name from
region_intersects(), and find_next_iomem_res() is an internal function.

Thanks,
-Toshi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>