Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt

2019-05-14 Thread Gautham R Shenoy
On Tue, May 14, 2019 at 05:02:16PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy"  writes:
> > From: "Gautham R. Shenoy" 
> >
> > Subject: Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock 
> > acquisition in resize_hpt
> 
> ps. A "RESEND" implies the patch is unchanged and you're just resending
> it because it was ignored.
> 
> In this case it should have just been "PATCH v2", with a note below the "---"
> saying "v2: Rebased onto powerpc/next ..."

Ok. I will send a v3 :-)

> 
> cheers
> 
> > During a memory hotplug operations involving resizing of the HPT, we
> > invoke a stop_machine() to perform the resizing. In this code path, we
> > end up recursively taking the cpu_hotplug_lock, first in
> > memory_hotplug_begin() and then subsequently in stop_machine(). This
> > causes the system to hang. With lockdep enabled we get the following
> > error message before the hang.
> >
> >   swapper/0/1 is trying to acquire lock:
> >   (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
> > stop_machine+0x2c/0x60
> >
> >   but task is already holding lock:
> >   (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
> > mem_hotplug_begin+0x20/0x50
> >
> >   other info that might help us debug this:
> >Possible unsafe locking scenario:
> >
> >  CPU0
> >  
> > lock(cpu_hotplug_lock.rw_sem);
> > lock(cpu_hotplug_lock.rw_sem);
> >
> >*** DEADLOCK ***
> >
> > Fix this issue by
> >   1) Requiring all the calls to pseries_lpar_resize_hpt() be made
> >  with cpu_hotplug_lock held.
> >
> >   2) In pseries_lpar_resize_hpt() invoke stop_machine_cpuslocked()
> >  as a consequence of 1)
> >
> >   3) To satisfy 1), in hpt_order_set(), call mmu_hash_ops.resize_hpt()
> >  with cpu_hotplug_lock held.
> >
> > Reported-by: Aneesh Kumar K.V 
> > Signed-off-by: Gautham R. Shenoy 
> > ---
> >
> > Rebased this one against powerpc/next instead of linux/master.
> >
> >  arch/powerpc/mm/book3s64/hash_utils.c | 9 -
> >  arch/powerpc/platforms/pseries/lpar.c | 8 ++--
> >  2 files changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/mm/book3s64/hash_utils.c 
> > b/arch/powerpc/mm/book3s64/hash_utils.c
> > index 919a861..d07fcafd 100644
> > --- a/arch/powerpc/mm/book3s64/hash_utils.c
> > +++ b/arch/powerpc/mm/book3s64/hash_utils.c
> > @@ -38,6 +38,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -1928,10 +1929,16 @@ static int hpt_order_get(void *data, u64 *val)
> >  
> >  static int hpt_order_set(void *data, u64 val)
> >  {
> > +   int ret;
> > +
> > if (!mmu_hash_ops.resize_hpt)
> > return -ENODEV;
> >  
> > -   return mmu_hash_ops.resize_hpt(val);
> > +   cpus_read_lock();
> > +   ret = mmu_hash_ops.resize_hpt(val);
> > +   cpus_read_unlock();
> > +
> > +   return ret;
> >  }
> >  
> >  DEFINE_DEBUGFS_ATTRIBUTE(fops_hpt_order, hpt_order_get, hpt_order_set, 
> > "%llu\n");
> > diff --git a/arch/powerpc/platforms/pseries/lpar.c 
> > b/arch/powerpc/platforms/pseries/lpar.c
> > index 1034ef1..2fc9756 100644
> > --- a/arch/powerpc/platforms/pseries/lpar.c
> > +++ b/arch/powerpc/platforms/pseries/lpar.c
> > @@ -859,7 +859,10 @@ static int pseries_lpar_resize_hpt_commit(void *data)
> > return 0;
> >  }
> >  
> > -/* Must be called in user context */
> > +/*
> > + * Must be called in user context. The caller should hold the
> > + * cpus_lock.
> > + */
> >  static int pseries_lpar_resize_hpt(unsigned long shift)
> >  {
> > struct hpt_resize_state state = {
> > @@ -913,7 +916,8 @@ static int pseries_lpar_resize_hpt(unsigned long shift)
> >  
> > t1 = ktime_get();
> >  
> > -   rc = stop_machine(pseries_lpar_resize_hpt_commit, , NULL);
> > +   rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> > +, NULL);
> >  
> > t2 = ktime_get();
> >  
> > -- 
> > 1.9.4
> 



Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt

2019-05-14 Thread Gautham R Shenoy
Hi Michael,

On Tue, May 14, 2019 at 05:00:19PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy"  writes:
> > From: "Gautham R. Shenoy" 
> >
> > During a memory hotplug operations involving resizing of the HPT, we
> > invoke a stop_machine() to perform the resizing. In this code path, we
> > end up recursively taking the cpu_hotplug_lock, first in
> > memory_hotplug_begin() and then subsequently in stop_machine(). This
> > causes the system to hang.
>
> This implies we have never tested a memory hotplug that resized the HPT.
> Is that really true? Or did something change?
>

This was reported by Aneesh during a testcase involving reconfiguring
the namespace for nvdimm where we do a memory remove followed by
add. The memory add invokes resize_hpt().

It seems we can hit this issue when we perform a memory hotplug/unplug
in the guest.

> > With lockdep enabled we get the following
> > error message before the hang.
> >
> >   swapper/0/1 is trying to acquire lock:
> >   (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
> > stop_machine+0x2c/0x60
> >
> >   but task is already holding lock:
> >   (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
> > mem_hotplug_begin+0x20/0x50
> 
> Do we have the full stack trace?

Yes, here is the complete log:

[0.537123] swapper/0/1 is trying to acquire lock:
[0.537197] (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
stop_machine+0x2c/0x60
[0.537336]
[0.537336] but task is already holding lock:
[0.537429] (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
mem_hotplug_begin+0x20/0x50

[0.537570]   
[0.537570] other info that might help us debug this:
[0.537663]  Possible unsafe locking scenario:
[0.537663]
[0.537756]CPU0 
[0.537794]   
[0.537832]   lock(cpu_hotplug_lock.rw_sem); 
   
[0.537906]   lock(cpu_hotplug_lock.rw_sem); 
[0.537980]   
[0.537980]  *** DEADLOCK ***
   
[0.537980]  

[0.538074]  May be due to missing lock nesting notation 
  
[0.538074]  
  
[0.538168] 3 locks held by swapper/0/1:   
[0.538224]  #0: (ptrval) (>mutex){}, at: 
__driver_attach+0x12c/0x1b0
[0.538348]  #1: (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
mem_hotplug_begin+0x20/0x50
[0.538477]  #2: (ptrval) (mem_hotplug_lock.rw_sem){}, at: 
percpu_down_write+0x54/0x1a0
[0.538608]
[0.538608] stack backtrace:  
[0.538685] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.0.0-rc5-58373-gbc99402235f3-dirty #166
[0.538812] Call Trace:  
[0.538863] [c000feb03150] [c0e32bd4] dump_stack+0xe8/0x164 
(unreliable)
[0.538975] [c000feb031a0] [c020d6c0] 
__lock_acquire+0x1110/0x1c70
[0.539086] [c000feb03320] [c020f080] lock_acquire+0x240/0x290
[0.539180] [c000feb033e0] [c017f554] cpus_read_lock+0x64/0xf0
[0.539273] [c000feb03420] [c029ebac] stop_machine+0x2c/0x60 
[0.539367] [c000feb03460] [c00d7f7c] 
pseries_lpar_resize_hpt+0x19c/0x2c0
[0.539479] [c000feb03500] [c00788d0] 
resize_hpt_for_hotplug+0x70/0xd0
[0.539590] [c000feb03570] [c0e5d278] arch_add_memory+0x58/0xfc
[0.539683] [c000feb03610] [c03553a8] 
devm_memremap_pages+0x5e8/0x8f0
[0.539804] [c000feb036c0] [c09c2394] 
pmem_attach_disk+0x764/0x830
[0.539916] [c000feb037d0] [c09a7c38] 
nvdimm_bus_probe+0x118/0x240
[0.540026] [c000feb03860] [c0968500] really_probe+0x230/0x4b0
[0.540119] [c000feb038f0] [c0968aec] 
driver_probe_device+0x16c/0x1e0
[0.540230] [c000feb03970] [c0968ca8] __driver_attach+0x148/0x1b0
[0.540340] [c000feb039f0] [c09650b0] bus_for_each_dev+0x90/0x130
[0.540451] [c000feb03a50] [c0967dd4] driver_attach+0x34/0x50
[0.540544] [c000feb03a70] [c0967068] bus_add_driver+0x1a8/0x360
[0.540654] [c000feb03b00] [c096a498] driver_register+0x108/0x170
[0.540766] [c000feb03b70] [c09a7400] 
__nd_driver_register+0xd0/0xf0
[0.540898] [c000feb03bd0] [c128aa90] 
nd_pmem_driver_init+0x34/0x48
[0.541010] [c000feb03bf0] [c0010a10] do_one_initcall+0x1e0/0x45c
[0.541122] [c000feb03cd0] [c122462c] 
kernel_init_freeable+0x540/0x64c  
[0.541232] [c000feb03db0] [c001110c] kernel_init+0x2c/0x160
[  

Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt

2019-05-14 Thread Michael Ellerman
"Gautham R. Shenoy"  writes:
> From: "Gautham R. Shenoy" 
>
> Subject: Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition 
> in resize_hpt

ps. A "RESEND" implies the patch is unchanged and you're just resending
it because it was ignored.

In this case it should have just been "PATCH v2", with a note below the "---"
saying "v2: Rebased onto powerpc/next ..."

cheers

> During a memory hotplug operations involving resizing of the HPT, we
> invoke a stop_machine() to perform the resizing. In this code path, we
> end up recursively taking the cpu_hotplug_lock, first in
> memory_hotplug_begin() and then subsequently in stop_machine(). This
> causes the system to hang. With lockdep enabled we get the following
> error message before the hang.
>
>   swapper/0/1 is trying to acquire lock:
>   (ptrval) (cpu_hotplug_lock.rw_sem){}, at: stop_machine+0x2c/0x60
>
>   but task is already holding lock:
>   (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
> mem_hotplug_begin+0x20/0x50
>
>   other info that might help us debug this:
>Possible unsafe locking scenario:
>
>  CPU0
>  
> lock(cpu_hotplug_lock.rw_sem);
> lock(cpu_hotplug_lock.rw_sem);
>
>*** DEADLOCK ***
>
> Fix this issue by
>   1) Requiring all the calls to pseries_lpar_resize_hpt() be made
>  with cpu_hotplug_lock held.
>
>   2) In pseries_lpar_resize_hpt() invoke stop_machine_cpuslocked()
>  as a consequence of 1)
>
>   3) To satisfy 1), in hpt_order_set(), call mmu_hash_ops.resize_hpt()
>  with cpu_hotplug_lock held.
>
> Reported-by: Aneesh Kumar K.V 
> Signed-off-by: Gautham R. Shenoy 
> ---
>
> Rebased this one against powerpc/next instead of linux/master.
>
>  arch/powerpc/mm/book3s64/hash_utils.c | 9 -
>  arch/powerpc/platforms/pseries/lpar.c | 8 ++--
>  2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/book3s64/hash_utils.c 
> b/arch/powerpc/mm/book3s64/hash_utils.c
> index 919a861..d07fcafd 100644
> --- a/arch/powerpc/mm/book3s64/hash_utils.c
> +++ b/arch/powerpc/mm/book3s64/hash_utils.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1928,10 +1929,16 @@ static int hpt_order_get(void *data, u64 *val)
>  
>  static int hpt_order_set(void *data, u64 val)
>  {
> + int ret;
> +
>   if (!mmu_hash_ops.resize_hpt)
>   return -ENODEV;
>  
> - return mmu_hash_ops.resize_hpt(val);
> + cpus_read_lock();
> + ret = mmu_hash_ops.resize_hpt(val);
> + cpus_read_unlock();
> +
> + return ret;
>  }
>  
>  DEFINE_DEBUGFS_ATTRIBUTE(fops_hpt_order, hpt_order_get, hpt_order_set, 
> "%llu\n");
> diff --git a/arch/powerpc/platforms/pseries/lpar.c 
> b/arch/powerpc/platforms/pseries/lpar.c
> index 1034ef1..2fc9756 100644
> --- a/arch/powerpc/platforms/pseries/lpar.c
> +++ b/arch/powerpc/platforms/pseries/lpar.c
> @@ -859,7 +859,10 @@ static int pseries_lpar_resize_hpt_commit(void *data)
>   return 0;
>  }
>  
> -/* Must be called in user context */
> +/*
> + * Must be called in user context. The caller should hold the
> + * cpus_lock.
> + */
>  static int pseries_lpar_resize_hpt(unsigned long shift)
>  {
>   struct hpt_resize_state state = {
> @@ -913,7 +916,8 @@ static int pseries_lpar_resize_hpt(unsigned long shift)
>  
>   t1 = ktime_get();
>  
> - rc = stop_machine(pseries_lpar_resize_hpt_commit, , NULL);
> + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> +  , NULL);
>  
>   t2 = ktime_get();
>  
> -- 
> 1.9.4


Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt

2019-05-14 Thread Michael Ellerman
"Gautham R. Shenoy"  writes:
> From: "Gautham R. Shenoy" 
>
> During a memory hotplug operations involving resizing of the HPT, we
> invoke a stop_machine() to perform the resizing. In this code path, we
> end up recursively taking the cpu_hotplug_lock, first in
> memory_hotplug_begin() and then subsequently in stop_machine(). This
> causes the system to hang.

This implies we have never tested a memory hotplug that resized the HPT.
Is that really true? Or did something change?

> With lockdep enabled we get the following
> error message before the hang.
>
>   swapper/0/1 is trying to acquire lock:
>   (ptrval) (cpu_hotplug_lock.rw_sem){}, at: stop_machine+0x2c/0x60
>
>   but task is already holding lock:
>   (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
> mem_hotplug_begin+0x20/0x50

Do we have the full stack trace?

>   other info that might help us debug this:
>Possible unsafe locking scenario:
>
>  CPU0
>  
> lock(cpu_hotplug_lock.rw_sem);
> lock(cpu_hotplug_lock.rw_sem);
>
>*** DEADLOCK ***
>
> Fix this issue by
>   1) Requiring all the calls to pseries_lpar_resize_hpt() be made
>  with cpu_hotplug_lock held.
>
>   2) In pseries_lpar_resize_hpt() invoke stop_machine_cpuslocked()
>  as a consequence of 1)
>
>   3) To satisfy 1), in hpt_order_set(), call mmu_hash_ops.resize_hpt()
>  with cpu_hotplug_lock held.
>
> Reported-by: Aneesh Kumar K.V 
> Signed-off-by: Gautham R. Shenoy 
> ---
>
> Rebased this one against powerpc/next instead of linux/master.
>
>  arch/powerpc/mm/book3s64/hash_utils.c | 9 -
>  arch/powerpc/platforms/pseries/lpar.c | 8 ++--
>  2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/book3s64/hash_utils.c 
> b/arch/powerpc/mm/book3s64/hash_utils.c
> index 919a861..d07fcafd 100644
> --- a/arch/powerpc/mm/book3s64/hash_utils.c
> +++ b/arch/powerpc/mm/book3s64/hash_utils.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1928,10 +1929,16 @@ static int hpt_order_get(void *data, u64 *val)
>  
>  static int hpt_order_set(void *data, u64 val)
>  {
> + int ret;
> +
>   if (!mmu_hash_ops.resize_hpt)
>   return -ENODEV;
>  
> - return mmu_hash_ops.resize_hpt(val);
> + cpus_read_lock();
> + ret = mmu_hash_ops.resize_hpt(val);
> + cpus_read_unlock();
> +
> + return ret;
>  }
>  
>  DEFINE_DEBUGFS_ATTRIBUTE(fops_hpt_order, hpt_order_get, hpt_order_set, 
> "%llu\n");
> diff --git a/arch/powerpc/platforms/pseries/lpar.c 
> b/arch/powerpc/platforms/pseries/lpar.c
> index 1034ef1..2fc9756 100644
> --- a/arch/powerpc/platforms/pseries/lpar.c
> +++ b/arch/powerpc/platforms/pseries/lpar.c
> @@ -859,7 +859,10 @@ static int pseries_lpar_resize_hpt_commit(void *data)
>   return 0;
>  }
>  
> -/* Must be called in user context */
> +/*
> + * Must be called in user context. The caller should hold the

I realise you're just copying that comment, but it seems wrong. "user
context" means userspace. I think it means "process context" doesn't it?

Also "should" should be "must" :)

> + * cpus_lock.
> + */
>  static int pseries_lpar_resize_hpt(unsigned long shift)
>  {
>   struct hpt_resize_state state = {
> @@ -913,7 +916,8 @@ static int pseries_lpar_resize_hpt(unsigned long shift)
>  
>   t1 = ktime_get();
>  
> - rc = stop_machine(pseries_lpar_resize_hpt_commit, , NULL);
> + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> +  , NULL);
>  
>   t2 = ktime_get();

cheers


[RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt

2019-05-10 Thread Gautham R. Shenoy
From: "Gautham R. Shenoy" 

During a memory hotplug operations involving resizing of the HPT, we
invoke a stop_machine() to perform the resizing. In this code path, we
end up recursively taking the cpu_hotplug_lock, first in
memory_hotplug_begin() and then subsequently in stop_machine(). This
causes the system to hang. With lockdep enabled we get the following
error message before the hang.

  swapper/0/1 is trying to acquire lock:
  (ptrval) (cpu_hotplug_lock.rw_sem){}, at: stop_machine+0x2c/0x60

  but task is already holding lock:
  (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
mem_hotplug_begin+0x20/0x50

  other info that might help us debug this:
   Possible unsafe locking scenario:

 CPU0
 
lock(cpu_hotplug_lock.rw_sem);
lock(cpu_hotplug_lock.rw_sem);

   *** DEADLOCK ***

Fix this issue by
  1) Requiring all the calls to pseries_lpar_resize_hpt() be made
 with cpu_hotplug_lock held.

  2) In pseries_lpar_resize_hpt() invoke stop_machine_cpuslocked()
 as a consequence of 1)

  3) To satisfy 1), in hpt_order_set(), call mmu_hash_ops.resize_hpt()
 with cpu_hotplug_lock held.

Reported-by: Aneesh Kumar K.V 
Signed-off-by: Gautham R. Shenoy 
---

Rebased this one against powerpc/next instead of linux/master.

 arch/powerpc/mm/book3s64/hash_utils.c | 9 -
 arch/powerpc/platforms/pseries/lpar.c | 8 ++--
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/hash_utils.c 
b/arch/powerpc/mm/book3s64/hash_utils.c
index 919a861..d07fcafd 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1928,10 +1929,16 @@ static int hpt_order_get(void *data, u64 *val)
 
 static int hpt_order_set(void *data, u64 val)
 {
+   int ret;
+
if (!mmu_hash_ops.resize_hpt)
return -ENODEV;
 
-   return mmu_hash_ops.resize_hpt(val);
+   cpus_read_lock();
+   ret = mmu_hash_ops.resize_hpt(val);
+   cpus_read_unlock();
+
+   return ret;
 }
 
 DEFINE_DEBUGFS_ATTRIBUTE(fops_hpt_order, hpt_order_get, hpt_order_set, 
"%llu\n");
diff --git a/arch/powerpc/platforms/pseries/lpar.c 
b/arch/powerpc/platforms/pseries/lpar.c
index 1034ef1..2fc9756 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -859,7 +859,10 @@ static int pseries_lpar_resize_hpt_commit(void *data)
return 0;
 }
 
-/* Must be called in user context */
+/*
+ * Must be called in user context. The caller should hold the
+ * cpus_lock.
+ */
 static int pseries_lpar_resize_hpt(unsigned long shift)
 {
struct hpt_resize_state state = {
@@ -913,7 +916,8 @@ static int pseries_lpar_resize_hpt(unsigned long shift)
 
t1 = ktime_get();
 
-   rc = stop_machine(pseries_lpar_resize_hpt_commit, , NULL);
+   rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
+, NULL);
 
t2 = ktime_get();
 
-- 
1.9.4