[PATCH rebased] powerpc/fadump: when fadump is supported register the fadump sysfs files.

Currently it is not possible to distinguish the case when fadump is
supported by firmware and disabled in kernel and completely unsupported
using the kernel sysfs interface. User can investigate the devicetree
but it is more reasonable to provide sysfs files in case we get some
fadumpv2 in the future.

With this patch sysfs files are available whenever fadump is supported
by firmware.

Signed-off-by: Michal Suchanek <redacted>
---
Rebase on top of http://patchwork.ozlabs.org/patch/1150160/
[v5,31/31] powernv/fadump: support holes in kernel boot memory area
---
 arch/powerpc/kernel/fadump.c | 33 ++++++++++++++++++---------------
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4b1bb3c55cf9..7ad424729e9c 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c

@@ -1319,13 +1319,9 @@ static void fadump_init_files(void)
  */
 int __init setup_fadump(void)
 {
-	if (!fw_dump.fadump_enabled)
-		return 0;
-
-	if (!fw_dump.fadump_supported) {
+	if (!fw_dump.fadump_supported && fw_dump.fadump_enabled) {
 		printk(KERN_ERR "Firmware-assisted dump is not supported on"
 			" this hardware\n");
-		return 0;
 	}
 
 	fadump_show_config();

@@ -1333,19 +1329,26 @@ int __init setup_fadump(void)
 	 * If dump data is available then see if it is valid and prepare for
 	 * saving it to the disk.
 	 */
-	if (fw_dump.dump_active) {
+	if (fw_dump.fadump_enabled) {
+		if (fw_dump.dump_active) {
+			/*
+			 * if dump process fails then invalidate the
+			 * registration and release memory before proceeding
+			 * for re-registration.
+			 */
+			if (fw_dump.ops->fadump_process(&fw_dump) < 0)
+				fadump_invalidate_release_mem();
+		}
 		/*
-		 * if dump process fails then invalidate the registration
-		 * and release memory before proceeding for re-registration.
+		 * Initialize the kernel dump memory structure for FAD
+		 * registration.
 		 */
-		if (fw_dump.ops->fadump_process(&fw_dump) < 0)
-			fadump_invalidate_release_mem();
-	}
-	/* Initialize the kernel dump memory structure for FAD registration. */
-	else if (fw_dump.reserve_dump_area_size)
-		fw_dump.ops->fadump_init_mem_struct(&fw_dump);
+		else if (fw_dump.reserve_dump_area_size)
+			fw_dump.ops->fadump_init_mem_struct(&fw_dump);
 
-	fadump_init_files();
+	}
+	if (fw_dump.fadump_supported)
+		fadump_init_files();
 
 	return 1;
 }

-- 
2.22.0

Hi Michal,

Thanks for the patch. 

On 20/08/19 11:42 PM, Michal Suchanek wrote:

Could you please move up fadump_init_files() call and return after it instead of
nesting rest of the function. Also, get rid of the error message when fadump is
not supported as it is already taken care of in fadump_reserve_mem() function.
I mean:

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 2015b1f..0e9b028 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c

@@ -1322,16 +1322,16 @@ static void fadump_init_files(void)
  */
 int __init setup_fadump(void)
 {
-       if (!fw_dump.fadump_enabled)
+       if (!fw_dump.fadump_supported)
                return 0;
 
-       if (!fw_dump.fadump_supported) {
-               printk(KERN_ERR "Firmware-assisted dump is not supported on"
-                       " this hardware\n");
-               return 0;
-       }
+       fadump_init_files();
 
        fadump_show_config();
+
+       if (!fw_dump.fadump_enabled)
+               return 0;
+
        /*
         * If dump data is available then see if it is valid and prepare for
         * saving it to the disk.

@@ -1348,8 +1348,6 @@ int __init setup_fadump(void)
        else if (fw_dump.reserve_dump_area_size)
                fw_dump.ops->fadump_init_mem_struct(&fw_dump);
 
-       fadump_init_files();
-
        return 1;
 }
 subsys_initcall(setup_fadump);


- Hari

On Tue, 27 Aug 2019 17:57:31 +0530
Hari Bathini [off-list ref] wrote:

Hi Michal,

Thanks for the patch. 

On 20/08/19 11:42 PM, Michal Suchanek wrote:

quoted

Currently it is not possible to distinguish the case when fadump is
supported by firmware and disabled in kernel and completely unsupported
using the kernel sysfs interface. User can investigate the devicetree
but it is more reasonable to provide sysfs files in case we get some
fadumpv2 in the future.

With this patch sysfs files are available whenever fadump is supported
by firmware.

Signed-off-by: Michal Suchanek <redacted>
---
Rebase on top of http://patchwork.ozlabs.org/patch/1150160/
[v5,31/31] powernv/fadump: support holes in kernel boot memory area
---
 arch/powerpc/kernel/fadump.c | 33 ++++++++++++++++++---------------
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4b1bb3c55cf9..7ad424729e9c 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c

@@ -1319,13 +1319,9 @@ static void fadump_init_files(void)
  */
 int __init setup_fadump(void)
 {
-	if (!fw_dump.fadump_enabled)
-		return 0;
-
-	if (!fw_dump.fadump_supported) {
+	if (!fw_dump.fadump_supported && fw_dump.fadump_enabled) {
 		printk(KERN_ERR "Firmware-assisted dump is not supported on"
 			" this hardware\n");
-		return 0;
 	}
 
 	fadump_show_config();

@@ -1333,19 +1329,26 @@ int __init setup_fadump(void)
 	 * If dump data is available then see if it is valid and prepare for
 	 * saving it to the disk.
 	 */
-	if (fw_dump.dump_active) {
+	if (fw_dump.fadump_enabled) {
+		if (fw_dump.dump_active) {
+			/*
+			 * if dump process fails then invalidate the
+			 * registration and release memory before proceeding
+			 * for re-registration.
+			 */
+			if (fw_dump.ops->fadump_process(&fw_dump) < 0)
+				fadump_invalidate_release_mem();
+		}
 		/*
-		 * if dump process fails then invalidate the registration
-		 * and release memory before proceeding for re-registration.
+		 * Initialize the kernel dump memory structure for FAD
+		 * registration.
 		 */
-		if (fw_dump.ops->fadump_process(&fw_dump) < 0)
-			fadump_invalidate_release_mem();
-	}
-	/* Initialize the kernel dump memory structure for FAD registration. */
-	else if (fw_dump.reserve_dump_area_size)
-		fw_dump.ops->fadump_init_mem_struct(&fw_dump);
+		else if (fw_dump.reserve_dump_area_size)
+			fw_dump.ops->fadump_init_mem_struct(&fw_dump);
 
-	fadump_init_files();
+	}
+	if (fw_dump.fadump_supported)
+		fadump_init_files();
 
 	return 1;
 }
  

Could you please move up fadump_init_files() call and return after it instead of
nesting rest of the function. 

That sounds reasonable.

Also, get rid of the error message when fadump is
not supported as it is already taken care of in fadump_reserve_mem() function.

That should not be called in that case, should it?

Anyway, I find the message right next to the message about reserving
memory for kdump. So it really looks helpful in the log.

Should the init function return 0 when it did something that needs to
be undone later (ie registering the sysfs files)? This is probably not
very meaningful for fadump but what is the correct way to not set a bad
example?

Thanks

Michal

Currently it is not possible to distinguish the case when fadump is
supported by firmware and disabled in kernel and completely unsupported
using the kernel sysfs interface. User can investigate the devicetree
but it is more reasonable to provide sysfs files in case we get some
fadumpv2 in the future.

With this patch sysfs files are available whenever fadump is supported
by firmware.

Signed-off-by: Michal Suchanek <redacted>
---
v2: move the sysfs initialization earlier to avoid condition nesting
---
 arch/powerpc/kernel/fadump.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4eab97292cc2..13741380b2f7 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c

@@ -1671,16 +1671,20 @@ static void fadump_init_files(void)
  */
 int __init setup_fadump(void)
 {
-	if (!fw_dump.fadump_enabled)
-		return 0;
-
-	if (!fw_dump.fadump_supported) {
+	if (!fw_dump.fadump_supported && fw_dump.fadump_enabled) {
 		printk(KERN_ERR "Firmware-assisted dump is not supported on"
 			" this hardware\n");
-		return 0;
 	}
 
+	if (!fw_dump.fadump_supported)
+		return 0;
+
+	fadump_init_files();
 	fadump_show_config();
+
+	if (!fw_dump.fadump_enabled)
+		return 1;
+
 	/*
 	 * If dump data is available then see if it is valid and prepare for
 	 * saving it to the disk.

@@ -1696,7 +1700,6 @@ int __init setup_fadump(void)
 	/* Initialize the kernel dump memory structure for FAD registration. */
 	else if (fw_dump.reserve_dump_area_size)
 		init_fadump_mem_struct(&fdm, fw_dump.reserve_dump_area_start);
-	fadump_init_files();
 
 	return 1;
 }

-- 
2.22.0

On 28/08/19 10:37 PM, Michal Suchánek wrote:

On Tue, 27 Aug 2019 17:57:31 +0530
Hari Bathini [off-list ref] wrote:

[...]

quoted

Also, get rid of the error message when fadump is
not supported as it is already taken care of in fadump_reserve_mem() function.

That should not be called in that case, should it?

fadump_reserve_mem() is called during early boot while this is an initcall that happens
later. Not sure if we can make the initcall conditional on fadump support though..

Anyway, I find the message right next to the message about reserving
memory for kdump. So it really looks helpful in the log.

The message you see right after memory reservation for kdump is coming from
fadump_reserve_mem() function. This is the repeat of the same message logged
much later...
 
- Hari

On 28/08/19 10:57 PM, Michal Suchanek wrote:

Currently it is not possible to distinguish the case when fadump is
supported by firmware and disabled in kernel and completely unsupported
using the kernel sysfs interface. User can investigate the devicetree
but it is more reasonable to provide sysfs files in case we get some
fadumpv2 in the future.

With this patch sysfs files are available whenever fadump is supported
by firmware.

Signed-off-by: Michal Suchanek <redacted>
---

[...]

-	if (!fw_dump.fadump_supported) {
+	if (!fw_dump.fadump_supported && fw_dump.fadump_enabled) {
 		printk(KERN_ERR "Firmware-assisted dump is not supported on"
 			" this hardware\n");
-		return 0;
 	}

The above hunk is redundant with similar message already logged during
early boot in fadump_reserve_mem() function. I am not strongly against
this though. So...


Acked-by: Hari Bathini <hbathini@linux.ibm.com>

On Thu, 29 Aug 2019 10:58:16 +0530
Hari Bathini [off-list ref] wrote:

On 28/08/19 10:57 PM, Michal Suchanek wrote:

quoted

Currently it is not possible to distinguish the case when fadump is
supported by firmware and disabled in kernel and completely unsupported
using the kernel sysfs interface. User can investigate the devicetree
but it is more reasonable to provide sysfs files in case we get some
fadumpv2 in the future.

With this patch sysfs files are available whenever fadump is supported
by firmware.

Signed-off-by: Michal Suchanek <redacted>
---  

[...]

quoted

-	if (!fw_dump.fadump_supported) {
+	if (!fw_dump.fadump_supported && fw_dump.fadump_enabled) {
 		printk(KERN_ERR "Firmware-assisted dump is not supported on"
 			" this hardware\n");
-		return 0;
 	}  

The above hunk is redundant with similar message already logged during
early boot in fadump_reserve_mem() function. I am not strongly against
this though. So...

I see this:
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Firmware-assisted dump is not supported on this hardware
[    0.000000] Reserving 256MB of memory at 128MB for crashkernel (System RAM: 8192MB)
[    0.000000] Allocated 5832704 bytes for 2048 pacas at c000000007a80000
[    0.000000] Page sizes from device-tree:
[    0.000000] base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0
[    0.000000] base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=1
[    0.000000] Page orders: linear mapping = 16, virtual = 16, io = 16, vmemmap = 16
[    0.000000] Using 1TB segments
[    0.000000] Initializing hash mmu with SLB

Clearly the second message is logged from the above code. The duplicate
is capitalized: "Firmware-Assisted Dump is not supported on this
hardware" and I don't see it logged. So if anything is duplicate that
should be removed it is the message in fadump_reserve_mem(). It is not
clear why that one is not seen, though.

Thanks

Michal