* [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
@ 2019-05-10 9:24 ` Gautham R. Shenoy
0 siblings, 0 replies; 10+ messages in thread
From: Gautham R. Shenoy @ 2019-05-10 9:24 UTC (permalink / raw)
To: Paul Mackerras, Nicholas Piggin, Michael Ellerman, Aneesh Kumar K.V
Cc: linuxppc-dev, linux-kernel, Gautham R. Shenoy
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
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 <aneesh.kumar@linux.ibm.com>
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
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 <linux/libfdt.h>
#include <linux/pkeys.h>
#include <linux/hugetlb.h>
+#include <linux/cpu.h>
#include <asm/debugfs.h>
#include <asm/processor.h>
@@ -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, &state, NULL);
+ rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
+ &state, NULL);
t2 = ktime_get();
--
1.9.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
@ 2019-05-10 9:24 ` Gautham R. Shenoy
0 siblings, 0 replies; 10+ messages in thread
From: Gautham R. Shenoy @ 2019-05-10 9:24 UTC (permalink / raw)
To: Paul Mackerras, Nicholas Piggin, Michael Ellerman, Aneesh Kumar K.V
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
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 <aneesh.kumar@linux.ibm.com>
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
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 <linux/libfdt.h>
#include <linux/pkeys.h>
#include <linux/hugetlb.h>
+#include <linux/cpu.h>
#include <asm/debugfs.h>
#include <asm/processor.h>
@@ -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, &state, NULL);
+ rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
+ &state, NULL);
t2 = ktime_get();
--
1.9.4
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
2019-05-10 9:24 ` Gautham R. Shenoy
@ 2019-05-14 7:00 ` Michael Ellerman
-1 siblings, 0 replies; 10+ messages in thread
From: Michael Ellerman @ 2019-05-14 7:00 UTC (permalink / raw)
To: Gautham R. Shenoy, Paul Mackerras, Nicholas Piggin, Aneesh Kumar K.V
Cc: linuxppc-dev, linux-kernel, Gautham R. Shenoy
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> 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 <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
>
> 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 <linux/libfdt.h>
> #include <linux/pkeys.h>
> #include <linux/hugetlb.h>
> +#include <linux/cpu.h>
>
> #include <asm/debugfs.h>
> #include <asm/processor.h>
> @@ -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, &state, NULL);
> + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> + &state, NULL);
>
> t2 = ktime_get();
cheers
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
@ 2019-05-14 7:00 ` Michael Ellerman
0 siblings, 0 replies; 10+ messages in thread
From: Michael Ellerman @ 2019-05-14 7:00 UTC (permalink / raw)
To: Gautham R. Shenoy, Paul Mackerras, Nicholas Piggin, Aneesh Kumar K.V
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> 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 <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
>
> 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 <linux/libfdt.h>
> #include <linux/pkeys.h>
> #include <linux/hugetlb.h>
> +#include <linux/cpu.h>
>
> #include <asm/debugfs.h>
> #include <asm/processor.h>
> @@ -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, &state, NULL);
> + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> + &state, NULL);
>
> t2 = ktime_get();
cheers
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
2019-05-10 9:24 ` Gautham R. Shenoy
@ 2019-05-14 7:02 ` Michael Ellerman
-1 siblings, 0 replies; 10+ messages in thread
From: Michael Ellerman @ 2019-05-14 7:02 UTC (permalink / raw)
To: Gautham R. Shenoy, Paul Mackerras, Nicholas Piggin, Aneesh Kumar K.V
Cc: linuxppc-dev, linux-kernel, Gautham R. Shenoy
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> 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 <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
>
> 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 <linux/libfdt.h>
> #include <linux/pkeys.h>
> #include <linux/hugetlb.h>
> +#include <linux/cpu.h>
>
> #include <asm/debugfs.h>
> #include <asm/processor.h>
> @@ -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, &state, NULL);
> + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> + &state, NULL);
>
> t2 = ktime_get();
>
> --
> 1.9.4
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
@ 2019-05-14 7:02 ` Michael Ellerman
0 siblings, 0 replies; 10+ messages in thread
From: Michael Ellerman @ 2019-05-14 7:02 UTC (permalink / raw)
To: Gautham R. Shenoy, Paul Mackerras, Nicholas Piggin, Aneesh Kumar K.V
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> 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 <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
>
> 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 <linux/libfdt.h>
> #include <linux/pkeys.h>
> #include <linux/hugetlb.h>
> +#include <linux/cpu.h>
>
> #include <asm/debugfs.h>
> #include <asm/processor.h>
> @@ -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, &state, NULL);
> + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> + &state, NULL);
>
> t2 = ktime_get();
>
> --
> 1.9.4
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
2019-05-14 7:00 ` Michael Ellerman
@ 2019-05-14 10:18 ` Gautham R Shenoy
-1 siblings, 0 replies; 10+ messages in thread
From: Gautham R Shenoy @ 2019-05-14 10:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R. Shenoy, Paul Mackerras, Nicholas Piggin,
Aneesh Kumar K.V, linuxppc-dev, linux-kernel
Hi Michael,
On Tue, May 14, 2019 at 05:00:19PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > 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____) (&dev->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] [c0000000feb03150] [c000000000e32bd4] dump_stack+0xe8/0x164 (unreliable)
[ 0.538975] [c0000000feb031a0] [c00000000020d6c0] __lock_acquire+0x1110/0x1c70
[ 0.539086] [c0000000feb03320] [c00000000020f080] lock_acquire+0x240/0x290
[ 0.539180] [c0000000feb033e0] [c00000000017f554] cpus_read_lock+0x64/0xf0
[ 0.539273] [c0000000feb03420] [c00000000029ebac] stop_machine+0x2c/0x60
[ 0.539367] [c0000000feb03460] [c0000000000d7f7c] pseries_lpar_resize_hpt+0x19c/0x2c0
[ 0.539479] [c0000000feb03500] [c0000000000788d0] resize_hpt_for_hotplug+0x70/0xd0
[ 0.539590] [c0000000feb03570] [c000000000e5d278] arch_add_memory+0x58/0xfc
[ 0.539683] [c0000000feb03610] [c0000000003553a8] devm_memremap_pages+0x5e8/0x8f0
[ 0.539804] [c0000000feb036c0] [c0000000009c2394] pmem_attach_disk+0x764/0x830
[ 0.539916] [c0000000feb037d0] [c0000000009a7c38] nvdimm_bus_probe+0x118/0x240
[ 0.540026] [c0000000feb03860] [c000000000968500] really_probe+0x230/0x4b0
[ 0.540119] [c0000000feb038f0] [c000000000968aec] driver_probe_device+0x16c/0x1e0
[ 0.540230] [c0000000feb03970] [c000000000968ca8] __driver_attach+0x148/0x1b0
[ 0.540340] [c0000000feb039f0] [c0000000009650b0] bus_for_each_dev+0x90/0x130
[ 0.540451] [c0000000feb03a50] [c000000000967dd4] driver_attach+0x34/0x50
[ 0.540544] [c0000000feb03a70] [c000000000967068] bus_add_driver+0x1a8/0x360
[ 0.540654] [c0000000feb03b00] [c00000000096a498] driver_register+0x108/0x170
[ 0.540766] [c0000000feb03b70] [c0000000009a7400] __nd_driver_register+0xd0/0xf0
[ 0.540898] [c0000000feb03bd0] [c00000000128aa90] nd_pmem_driver_init+0x34/0x48
[ 0.541010] [c0000000feb03bf0] [c000000000010a10] do_one_initcall+0x1e0/0x45c
[ 0.541122] [c0000000feb03cd0] [c00000000122462c] kernel_init_freeable+0x540/0x64c
[ 0.541232] [c0000000feb03db0] [c00000000001110c] kernel_init+0x2c/0x160
[ 0.541326] [c0000000feb03e20] [c00000000000bed4] ret_from_kernel_thread+0x5c/0x68
>
> > 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 <aneesh.kumar@linux.ibm.com>
> > Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> > ---
> >
> > 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 <linux/libfdt.h>
> > #include <linux/pkeys.h>
> > #include <linux/hugetlb.h>
> > +#include <linux/cpu.h>
> >
> > #include <asm/debugfs.h>
> > #include <asm/processor.h>
> > @@ -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?
>
Yes, from the qemu process context. I will fix this part of the
comment and also change the should to must.
> Also "should" should be "must" :)
>
Thanks for the review.
> > + * 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, &state, NULL);
> > + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> > + &state, NULL);
> >
> > t2 = ktime_get();
>
> cheers
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
@ 2019-05-14 10:18 ` Gautham R Shenoy
0 siblings, 0 replies; 10+ messages in thread
From: Gautham R Shenoy @ 2019-05-14 10:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R. Shenoy, Aneesh Kumar K.V, linux-kernel,
Nicholas Piggin, Paul Mackerras, linuxppc-dev
Hi Michael,
On Tue, May 14, 2019 at 05:00:19PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > 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____) (&dev->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] [c0000000feb03150] [c000000000e32bd4] dump_stack+0xe8/0x164 (unreliable)
[ 0.538975] [c0000000feb031a0] [c00000000020d6c0] __lock_acquire+0x1110/0x1c70
[ 0.539086] [c0000000feb03320] [c00000000020f080] lock_acquire+0x240/0x290
[ 0.539180] [c0000000feb033e0] [c00000000017f554] cpus_read_lock+0x64/0xf0
[ 0.539273] [c0000000feb03420] [c00000000029ebac] stop_machine+0x2c/0x60
[ 0.539367] [c0000000feb03460] [c0000000000d7f7c] pseries_lpar_resize_hpt+0x19c/0x2c0
[ 0.539479] [c0000000feb03500] [c0000000000788d0] resize_hpt_for_hotplug+0x70/0xd0
[ 0.539590] [c0000000feb03570] [c000000000e5d278] arch_add_memory+0x58/0xfc
[ 0.539683] [c0000000feb03610] [c0000000003553a8] devm_memremap_pages+0x5e8/0x8f0
[ 0.539804] [c0000000feb036c0] [c0000000009c2394] pmem_attach_disk+0x764/0x830
[ 0.539916] [c0000000feb037d0] [c0000000009a7c38] nvdimm_bus_probe+0x118/0x240
[ 0.540026] [c0000000feb03860] [c000000000968500] really_probe+0x230/0x4b0
[ 0.540119] [c0000000feb038f0] [c000000000968aec] driver_probe_device+0x16c/0x1e0
[ 0.540230] [c0000000feb03970] [c000000000968ca8] __driver_attach+0x148/0x1b0
[ 0.540340] [c0000000feb039f0] [c0000000009650b0] bus_for_each_dev+0x90/0x130
[ 0.540451] [c0000000feb03a50] [c000000000967dd4] driver_attach+0x34/0x50
[ 0.540544] [c0000000feb03a70] [c000000000967068] bus_add_driver+0x1a8/0x360
[ 0.540654] [c0000000feb03b00] [c00000000096a498] driver_register+0x108/0x170
[ 0.540766] [c0000000feb03b70] [c0000000009a7400] __nd_driver_register+0xd0/0xf0
[ 0.540898] [c0000000feb03bd0] [c00000000128aa90] nd_pmem_driver_init+0x34/0x48
[ 0.541010] [c0000000feb03bf0] [c000000000010a10] do_one_initcall+0x1e0/0x45c
[ 0.541122] [c0000000feb03cd0] [c00000000122462c] kernel_init_freeable+0x540/0x64c
[ 0.541232] [c0000000feb03db0] [c00000000001110c] kernel_init+0x2c/0x160
[ 0.541326] [c0000000feb03e20] [c00000000000bed4] ret_from_kernel_thread+0x5c/0x68
>
> > 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 <aneesh.kumar@linux.ibm.com>
> > Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> > ---
> >
> > 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 <linux/libfdt.h>
> > #include <linux/pkeys.h>
> > #include <linux/hugetlb.h>
> > +#include <linux/cpu.h>
> >
> > #include <asm/debugfs.h>
> > #include <asm/processor.h>
> > @@ -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?
>
Yes, from the qemu process context. I will fix this part of the
comment and also change the should to must.
> Also "should" should be "must" :)
>
Thanks for the review.
> > + * 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, &state, NULL);
> > + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> > + &state, NULL);
> >
> > t2 = ktime_get();
>
> cheers
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
2019-05-14 7:02 ` Michael Ellerman
@ 2019-05-14 10:18 ` Gautham R Shenoy
-1 siblings, 0 replies; 10+ messages in thread
From: Gautham R Shenoy @ 2019-05-14 10:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R. Shenoy, Paul Mackerras, Nicholas Piggin,
Aneesh Kumar K.V, linuxppc-dev, linux-kernel
On Tue, May 14, 2019 at 05:02:16PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > 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 <aneesh.kumar@linux.ibm.com>
> > Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> > ---
> >
> > 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 <linux/libfdt.h>
> > #include <linux/pkeys.h>
> > #include <linux/hugetlb.h>
> > +#include <linux/cpu.h>
> >
> > #include <asm/debugfs.h>
> > #include <asm/processor.h>
> > @@ -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, &state, NULL);
> > + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> > + &state, NULL);
> >
> > t2 = ktime_get();
> >
> > --
> > 1.9.4
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt
@ 2019-05-14 10:18 ` Gautham R Shenoy
0 siblings, 0 replies; 10+ messages in thread
From: Gautham R Shenoy @ 2019-05-14 10:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R. Shenoy, Aneesh Kumar K.V, linux-kernel,
Nicholas Piggin, Paul Mackerras, linuxppc-dev
On Tue, May 14, 2019 at 05:02:16PM +1000, Michael Ellerman wrote:
> "Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > 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 <aneesh.kumar@linux.ibm.com>
> > Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> > ---
> >
> > 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 <linux/libfdt.h>
> > #include <linux/pkeys.h>
> > #include <linux/hugetlb.h>
> > +#include <linux/cpu.h>
> >
> > #include <asm/debugfs.h>
> > #include <asm/processor.h>
> > @@ -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, &state, NULL);
> > + rc = stop_machine_cpuslocked(pseries_lpar_resize_hpt_commit,
> > + &state, NULL);
> >
> > t2 = ktime_get();
> >
> > --
> > 1.9.4
>
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-05-14 10:21 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-10 9:24 [RESEND PATCH] powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt Gautham R. Shenoy
2019-05-10 9:24 ` Gautham R. Shenoy
2019-05-14 7:00 ` Michael Ellerman
2019-05-14 7:00 ` Michael Ellerman
2019-05-14 10:18 ` Gautham R Shenoy
2019-05-14 10:18 ` Gautham R Shenoy
2019-05-14 7:02 ` Michael Ellerman
2019-05-14 7:02 ` Michael Ellerman
2019-05-14 10:18 ` Gautham R Shenoy
2019-05-14 10:18 ` Gautham R Shenoy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.