powerpc/fadump: re-register firmware-assisted dump if already registered

Message ID 153693396241.22873.15797641996113409474.stgit@hbathini.in.ibm.com
State New
Headers show
Series
  • powerpc/fadump: re-register firmware-assisted dump if already registered
Related show

Checks

Context Check Description
snowpatch_ozlabs/build-ppc32 success Test build-ppc32 on branch next
snowpatch_ozlabs/build-ppc64e success Test build-ppc64e on branch next
snowpatch_ozlabs/build-ppc64be success Test build-ppc64be on branch next
snowpatch_ozlabs/build-ppc64le success Test build-ppc64le on branch next
snowpatch_ozlabs/checkpatch success Test checkpatch on branch next
snowpatch_ozlabs/apply_patch success next/apply_patch Successfully applied

Commit Message

Hari Bathini Sept. 14, 2018, 2:06 p.m.
Firmware-Assisted Dump (FADump) needs to be registered again after any
memory hot add/remove operation to update the crash memory ranges. But
currently, the kernel returns '-EEXIST' if we try to register without
uregistering it first. This could expose the system to racing issues
while unregistering and registering FADump from userspace during udev
events. Spare the userspace of this and let it be taken care of in the
kernel space for a simpler interface.

Since this change, running 'echo 1 > /sys/kernel/fadump_registered'
would result in re-regisering (unregistering and registering) FADump,
if it was already registered.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
 arch/powerpc/kernel/fadump.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Petr Tesarik Sept. 14, 2018, 2:28 p.m. | #1
On Fri, 14 Sep 2018 19:36:02 +0530
Hari Bathini <hbathini@linux.ibm.com> wrote:

> Firmware-Assisted Dump (FADump) needs to be registered again after any
> memory hot add/remove operation to update the crash memory ranges. But
> currently, the kernel returns '-EEXIST' if we try to register without
> uregistering it first. This could expose the system to racing issues
> while unregistering and registering FADump from userspace during udev
> events. Spare the userspace of this and let it be taken care of in the
> kernel space for a simpler interface.
> 
> Since this change, running 'echo 1 > /sys/kernel/fadump_registered'
> would result in re-regisering (unregistering and registering) FADump,
> if it was already registered.

Great improvement to the API!

Any suggestions what should be done in a client which tries to be
compatible with kernels before this change and after this change?

Petr T

> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> ---
>  arch/powerpc/kernel/fadump.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index a711d22..761b28b 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -1444,8 +1444,8 @@ static ssize_t fadump_register_store(struct kobject *kobj,
>  		break;
>  	case 1:
>  		if (fw_dump.dump_registered == 1) {
> -			ret = -EEXIST;
> -			goto unlock_out;
> +			/* Un-register Firmware-assisted dump */
> +			fadump_unregister_dump(&fdm);
>  		}
>  		/* Register Firmware-assisted dump */
>  		ret = register_fadump();
>
Hari Bathini Sept. 14, 2018, 3:38 p.m. | #2
On Friday 14 September 2018 07:58 PM, Petr Tesarik wrote:
> On Fri, 14 Sep 2018 19:36:02 +0530
> Hari Bathini <hbathini@linux.ibm.com> wrote:
>
>> Firmware-Assisted Dump (FADump) needs to be registered again after any
>> memory hot add/remove operation to update the crash memory ranges. But
>> currently, the kernel returns '-EEXIST' if we try to register without
>> uregistering it first. This could expose the system to racing issues
>> while unregistering and registering FADump from userspace during udev
>> events. Spare the userspace of this and let it be taken care of in the
>> kernel space for a simpler interface.
>>
>> Since this change, running 'echo 1 > /sys/kernel/fadump_registered'
>> would result in re-regisering (unregistering and registering) FADump,
>> if it was already registered.
> Great improvement to the API!
>
> Any suggestions what should be done in a client which tries to be
> compatible with kernels before this change and after this change?

If `echo 1 > /sys/kernel/fadump_registered` fails, check for the output
of  `cat /sys/kernel/fadump_registered` and if it is still `1`, that 
indicates
old kernel and we are already registered. Treat it as success if being
registered is what we care about or unregister/register (if re-register
is the intention)..

Hope that helps..

Thanks
Hari
Mahesh Jagannath Salgaonkar Sept. 18, 2018, 4:46 p.m. | #3
On 09/14/2018 07:36 PM, Hari Bathini wrote:
> Firmware-Assisted Dump (FADump) needs to be registered again after any
> memory hot add/remove operation to update the crash memory ranges. But
> currently, the kernel returns '-EEXIST' if we try to register without
> uregistering it first. This could expose the system to racing issues
> while unregistering and registering FADump from userspace during udev
> events. Spare the userspace of this and let it be taken care of in the
> kernel space for a simpler interface.
> 
> Since this change, running 'echo 1 > /sys/kernel/fadump_registered'
> would result in re-regisering (unregistering and registering) FADump,
> if it was already registered.
> 
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>

Looks good to me.

Acked-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>

Thanks,
-Mahesh.

> ---
>  arch/powerpc/kernel/fadump.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index a711d22..761b28b 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -1444,8 +1444,8 @@ static ssize_t fadump_register_store(struct kobject *kobj,
>  		break;
>  	case 1:
>  		if (fw_dump.dump_registered == 1) {
> -			ret = -EEXIST;
> -			goto unlock_out;
> +			/* Un-register Firmware-assisted dump */
> +			fadump_unregister_dump(&fdm);
>  		}
>  		/* Register Firmware-assisted dump */
>  		ret = register_fadump();
>

Patch

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index a711d22..761b28b 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1444,8 +1444,8 @@  static ssize_t fadump_register_store(struct kobject *kobj,
 		break;
 	case 1:
 		if (fw_dump.dump_registered == 1) {
-			ret = -EEXIST;
-			goto unlock_out;
+			/* Un-register Firmware-assisted dump */
+			fadump_unregister_dump(&fdm);
 		}
 		/* Register Firmware-assisted dump */
 		ret = register_fadump();