Re: [PATCH] kdumpctl: make reload fail proof

[Kairui Song]

On Wed, Oct 30, 2019 at 7:32 PM Hari Bathini <hbathini(a)linux.ibm.com&gt; wrote:
>  When large amount of memory, about 1TB, is removed with DLPAR memory
>  remove operation, kdump reload could fail due to race condition with
>  device tree property update. In such scenario, the subsequent kdump
>  reload requests would also fail as reload() only proceeds if current
>  load status is active. Since the possibility of this race condition
>  couldn't be wished away due to the nature of the scenario, workaround
>  it by proceeding to load even if current load status is not active as
>  long as kdump service is active, which kdump udev rules already check
>  for.
>
>  Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com&gt;
>  ---
>   kdumpctl |    3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
>
>  diff --git a/kdumpctl b/kdumpctl
>  index 048e9f5..2d21a41 100755
>  --- a/kdumpctl
>  +++ b/kdumpctl
>  @@ -1116,8 +1116,7 @@ reload()
>   {
>          check_current_status
>          if [ $? -ne 0 ]; then
>  -               echo "Kdump is not running: [WARNING]"
>  -               return 0
>  +               echo "Kdump was not running: [WARNING]"
>          fi
>
>          if [ $DEFAULT_DUMP_MODE == "fadump" ]; then
>  
Looks good to me, Acked

--
Best Regards,
Kairui Song