From: Kai Shen <[email protected]>
spinlock recursion happened when do LTP test:
#!/bin/bash
./runltp -p -f hugetlb &
./runltp -p -f hugetlb &
./runltp -p -f hugetlb &
./runltp -p -f hugetlb &
./runltp -p -f hugetlb &
The dtor returned by get_compound_page_dtor in __put_compound_page
may be the function of free_huge_page which will lock the hugetlb_lock,
so don't put_page in lock of hugetlb_lock.
BUG: spinlock recursion on CPU#0, hugemmap05/1079
lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
Call trace:
dump_backtrace+0x0/0x198
show_stack+0x24/0x30
dump_stack+0xa4/0xcc
spin_dump+0x84/0xa8
do_raw_spin_lock+0xd0/0x108
_raw_spin_lock+0x20/0x30
free_huge_page+0x9c/0x260
__put_compound_page+0x44/0x50
__put_page+0x2c/0x60
alloc_surplus_huge_page.constprop.19+0xf0/0x140
hugetlb_acct_memory+0x104/0x378
hugetlb_reserve_pages+0xe0/0x250
hugetlbfs_file_mmap+0xc0/0x140
mmap_region+0x3e8/0x5b0
do_mmap+0x280/0x460
vm_mmap_pgoff+0xf4/0x128
ksys_mmap_pgoff+0xb4/0x258
__arm64_sys_mmap+0x34/0x48
el0_svc_common+0x78/0x130
el0_svc_handler+0x38/0x78
el0_svc+0x8/0xc
Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
Signed-off-by: Kai Shen <[email protected]>
Signed-off-by: Feilong Lin <[email protected]>
Reported-by: Wang Wang <[email protected]>
---
mm/hugetlb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6cdc7b2..c1e7b81 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1574,8 +1574,9 @@ static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
*/
if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
SetPageHugeTemporary(page);
+ spin_unlock(&hugetlb_lock);
put_page(page);
- page = NULL;
+ return NULL;
} else {
h->surplus_huge_pages++;
h->surplus_huge_pages_node[page_to_nid(page)]++;
--
1.8.3.1
On Sat 04-05-19 20:28:24, Zhiqiang Liu wrote:
> From: Kai Shen <[email protected]>
>
> spinlock recursion happened when do LTP test:
> #!/bin/bash
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
>
> The dtor returned by get_compound_page_dtor in __put_compound_page
> may be the function of free_huge_page which will lock the hugetlb_lock,
> so don't put_page in lock of hugetlb_lock.
>
> BUG: spinlock recursion on CPU#0, hugemmap05/1079
> lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
> Call trace:
> dump_backtrace+0x0/0x198
> show_stack+0x24/0x30
> dump_stack+0xa4/0xcc
> spin_dump+0x84/0xa8
> do_raw_spin_lock+0xd0/0x108
> _raw_spin_lock+0x20/0x30
> free_huge_page+0x9c/0x260
> __put_compound_page+0x44/0x50
> __put_page+0x2c/0x60
> alloc_surplus_huge_page.constprop.19+0xf0/0x140
> hugetlb_acct_memory+0x104/0x378
> hugetlb_reserve_pages+0xe0/0x250
> hugetlbfs_file_mmap+0xc0/0x140
> mmap_region+0x3e8/0x5b0
> do_mmap+0x280/0x460
> vm_mmap_pgoff+0xf4/0x128
> ksys_mmap_pgoff+0xb4/0x258
> __arm64_sys_mmap+0x34/0x48
> el0_svc_common+0x78/0x130
> el0_svc_handler+0x38/0x78
> el0_svc+0x8/0xc
>
> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
> Signed-off-by: Kai Shen <[email protected]>
> Signed-off-by: Feilong Lin <[email protected]>
> Reported-by: Wang Wang <[email protected]>
You are right. I must have completely missed that put_page path
unconditionally takes the hugetlb_lock for hugetlb pages.
Thanks for fixing this. I think this should be marked for stable
because it is not hard to imagine a regular user might trigger this.
Acked-by: Michal Hocko <[email protected]>
> ---
> mm/hugetlb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 6cdc7b2..c1e7b81 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1574,8 +1574,9 @@ static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
> */
> if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> SetPageHugeTemporary(page);
> + spin_unlock(&hugetlb_lock);
> put_page(page);
> - page = NULL;
> + return NULL;
> } else {
> h->surplus_huge_pages++;
> h->surplus_huge_pages_node[page_to_nid(page)]++;
> --
> 1.8.3.1
>
>
--
Michal Hocko
SUSE Labs
> On Sat 04-05-19 20:28:24, Zhiqiang Liu wrote:
>> From: Kai Shen <[email protected]>
>>
>> spinlock recursion happened when do LTP test:
>> #!/bin/bash
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>>
>> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
>> Signed-off-by: Kai Shen <[email protected]>
>> Signed-off-by: Feilong Lin <[email protected]>
>> Reported-by: Wang Wang <[email protected]>
>
> You are right. I must have completely missed that put_page path
> unconditionally takes the hugetlb_lock for hugetlb pages.
>
> Thanks for fixing this. I think this should be marked for stable
> because it is not hard to imagine a regular user might trigger this.
>
> Acked-by: Michal Hocko <[email protected]>
Thank you for your reply.
I will add Acked-by: Michal Hocko <[email protected]> in the v2 patch.
From: Kai Shen <[email protected]>
spinlock recursion happened when do LTP test:
#!/bin/bash
./runltp -p -f hugetlb &
./runltp -p -f hugetlb &
./runltp -p -f hugetlb &
./runltp -p -f hugetlb &
./runltp -p -f hugetlb &
The dtor returned by get_compound_page_dtor in __put_compound_page
may be the function of free_huge_page which will lock the hugetlb_lock,
so don't put_page in lock of hugetlb_lock.
BUG: spinlock recursion on CPU#0, hugemmap05/1079
lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
Call trace:
dump_backtrace+0x0/0x198
show_stack+0x24/0x30
dump_stack+0xa4/0xcc
spin_dump+0x84/0xa8
do_raw_spin_lock+0xd0/0x108
_raw_spin_lock+0x20/0x30
free_huge_page+0x9c/0x260
__put_compound_page+0x44/0x50
__put_page+0x2c/0x60
alloc_surplus_huge_page.constprop.19+0xf0/0x140
hugetlb_acct_memory+0x104/0x378
hugetlb_reserve_pages+0xe0/0x250
hugetlbfs_file_mmap+0xc0/0x140
mmap_region+0x3e8/0x5b0
do_mmap+0x280/0x460
vm_mmap_pgoff+0xf4/0x128
ksys_mmap_pgoff+0xb4/0x258
__arm64_sys_mmap+0x34/0x48
el0_svc_common+0x78/0x130
el0_svc_handler+0x38/0x78
el0_svc+0x8/0xc
Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
Signed-off-by: Kai Shen <[email protected]>
Signed-off-by: Feilong Lin <[email protected]>
Reported-by: Wang Wang <[email protected]>
Acked-by: Michal Hocko <[email protected]>
---
v1->v2: add Acked-by: Michal Hocko <[email protected]>
mm/hugetlb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6cdc7b2..c1e7b81 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1574,8 +1574,9 @@ static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
*/
if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
SetPageHugeTemporary(page);
+ spin_unlock(&hugetlb_lock);
put_page(page);
- page = NULL;
+ return NULL;
} else {
h->surplus_huge_pages++;
h->surplus_huge_pages_node[page_to_nid(page)]++;
--
1.8.3.1
On Mon 06-05-19 22:06:38, Zhiqiang Liu wrote:
> From: Kai Shen <[email protected]>
>
> spinlock recursion happened when do LTP test:
> #!/bin/bash
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
>
> The dtor returned by get_compound_page_dtor in __put_compound_page
> may be the function of free_huge_page which will lock the hugetlb_lock,
> so don't put_page in lock of hugetlb_lock.
>
> BUG: spinlock recursion on CPU#0, hugemmap05/1079
> lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
> Call trace:
> dump_backtrace+0x0/0x198
> show_stack+0x24/0x30
> dump_stack+0xa4/0xcc
> spin_dump+0x84/0xa8
> do_raw_spin_lock+0xd0/0x108
> _raw_spin_lock+0x20/0x30
> free_huge_page+0x9c/0x260
> __put_compound_page+0x44/0x50
> __put_page+0x2c/0x60
> alloc_surplus_huge_page.constprop.19+0xf0/0x140
> hugetlb_acct_memory+0x104/0x378
> hugetlb_reserve_pages+0xe0/0x250
> hugetlbfs_file_mmap+0xc0/0x140
> mmap_region+0x3e8/0x5b0
> do_mmap+0x280/0x460
> vm_mmap_pgoff+0xf4/0x128
> ksys_mmap_pgoff+0xb4/0x258
> __arm64_sys_mmap+0x34/0x48
> el0_svc_common+0x78/0x130
> el0_svc_handler+0x38/0x78
> el0_svc+0x8/0xc
>
> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
> Signed-off-by: Kai Shen <[email protected]>
> Signed-off-by: Feilong Lin <[email protected]>
> Reported-by: Wang Wang <[email protected]>
> Acked-by: Michal Hocko <[email protected]>
> ---
> v1->v2: add Acked-by: Michal Hocko <[email protected]>
A new version for single ack is usually an overkill and only makes the
situation more confusing. You have also didn't add Cc: stable as
suggested during the review. That part is arguably more important.
You also haven't CCed Andrew (now done) and your patch will not get
merged without him applying it. Anyway, let's wait for Andrew to pick
this patch up.
>
> mm/hugetlb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 6cdc7b2..c1e7b81 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1574,8 +1574,9 @@ static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
> */
> if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
> SetPageHugeTemporary(page);
> + spin_unlock(&hugetlb_lock);
> put_page(page);
> - page = NULL;
> + return NULL;
> } else {
> h->surplus_huge_pages++;
> h->surplus_huge_pages_node[page_to_nid(page)]++;
> --
> 1.8.3.1
>
--
Michal Hocko
SUSE Labs
On Mon, May 06, 2019 at 10:06:38PM +0800, Zhiqiang Liu wrote:
> From: Kai Shen <[email protected]>
>
> spinlock recursion happened when do LTP test:
> #!/bin/bash
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
>
> The dtor returned by get_compound_page_dtor in __put_compound_page
> may be the function of free_huge_page which will lock the hugetlb_lock,
> so don't put_page in lock of hugetlb_lock.
>
> BUG: spinlock recursion on CPU#0, hugemmap05/1079
> lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
> Call trace:
> dump_backtrace+0x0/0x198
> show_stack+0x24/0x30
> dump_stack+0xa4/0xcc
> spin_dump+0x84/0xa8
> do_raw_spin_lock+0xd0/0x108
> _raw_spin_lock+0x20/0x30
> free_huge_page+0x9c/0x260
> __put_compound_page+0x44/0x50
> __put_page+0x2c/0x60
> alloc_surplus_huge_page.constprop.19+0xf0/0x140
> hugetlb_acct_memory+0x104/0x378
> hugetlb_reserve_pages+0xe0/0x250
> hugetlbfs_file_mmap+0xc0/0x140
> mmap_region+0x3e8/0x5b0
> do_mmap+0x280/0x460
> vm_mmap_pgoff+0xf4/0x128
> ksys_mmap_pgoff+0xb4/0x258
> __arm64_sys_mmap+0x34/0x48
> el0_svc_common+0x78/0x130
> el0_svc_handler+0x38/0x78
> el0_svc+0x8/0xc
>
> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
> Signed-off-by: Kai Shen <[email protected]>
> Signed-off-by: Feilong Lin <[email protected]>
> Reported-by: Wang Wang <[email protected]>
> Acked-by: Michal Hocko <[email protected]>
Reviewed-by: Oscar Salvador <[email protected]>
--
Oscar Salvador
SUSE L3
> On Mon 06-05-19 22:06:38, Zhiqiang Liu wrote:
>> From: Kai Shen <[email protected]>
>>
>> spinlock recursion happened when do LTP test:
>> #!/bin/bash
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>>
>> The dtor returned by get_compound_page_dtor in __put_compound_page
>> may be the function of free_huge_page which will lock the hugetlb_lock,
>> so don't put_page in lock of hugetlb_lock.
>>
>> BUG: spinlock recursion on CPU#0, hugemmap05/1079
>> lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
>> Call trace:
>> dump_backtrace+0x0/0x198
>> show_stack+0x24/0x30
>> dump_stack+0xa4/0xcc
>> spin_dump+0x84/0xa8
>> do_raw_spin_lock+0xd0/0x108
>> _raw_spin_lock+0x20/0x30
>> free_huge_page+0x9c/0x260
>> __put_compound_page+0x44/0x50
>> __put_page+0x2c/0x60
>> alloc_surplus_huge_page.constprop.19+0xf0/0x140
>> hugetlb_acct_memory+0x104/0x378
>> hugetlb_reserve_pages+0xe0/0x250
>> hugetlbfs_file_mmap+0xc0/0x140
>> mmap_region+0x3e8/0x5b0
>> do_mmap+0x280/0x460
>> vm_mmap_pgoff+0xf4/0x128
>> ksys_mmap_pgoff+0xb4/0x258
>> __arm64_sys_mmap+0x34/0x48
>> el0_svc_common+0x78/0x130
>> el0_svc_handler+0x38/0x78
>> el0_svc+0x8/0xc
>>
>> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
>> Signed-off-by: Kai Shen <[email protected]>
>> Signed-off-by: Feilong Lin <[email protected]>
>> Reported-by: Wang Wang <[email protected]>
>> Acked-by: Michal Hocko <[email protected]>
>> ---
>> v1->v2: add Acked-by: Michal Hocko <[email protected]>
>
> A new version for single ack is usually an overkill and only makes the
> situation more confusing. You have also didn't add Cc: stable as
> suggested during the review. That part is arguably more important.
>
> You also haven't CCed Andrew (now done) and your patch will not get
> merged without him applying it. Anyway, let's wait for Andrew to pick
> this patch up.
>
Thank you for your patience. I am sorry for misunderstanding your advice
in your last mail.
Does adding Cc: stable mean adding Cc: <[email protected]>
tag in the patch or Ccing [email protected] when sending the new mail?
You are very nice. Thanks again.
>> mm/hugetlb.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 6cdc7b2..c1e7b81 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -1574,8 +1574,9 @@ static struct page *alloc_surplus_huge_page(struct hstate *h, gfp_t gfp_mask,
>> */
>> if (h->surplus_huge_pages >= h->nr_overcommit_huge_pages) {
>> SetPageHugeTemporary(page);
>> + spin_unlock(&hugetlb_lock);
>> put_page(page);
>> - page = NULL;
>> + return NULL;
>> } else {
>> h->surplus_huge_pages++;
>> h->surplus_huge_pages_node[page_to_nid(page)]++;
>> --
>> 1.8.3.1
>>
>
On 5/6/19 7:06 AM, Zhiqiang Liu wrote:
> From: Kai Shen <[email protected]>
>
> spinlock recursion happened when do LTP test:
> #!/bin/bash
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
>
> The dtor returned by get_compound_page_dtor in __put_compound_page
> may be the function of free_huge_page which will lock the hugetlb_lock,
> so don't put_page in lock of hugetlb_lock.
>
> BUG: spinlock recursion on CPU#0, hugemmap05/1079
> lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
> Call trace:
> dump_backtrace+0x0/0x198
> show_stack+0x24/0x30
> dump_stack+0xa4/0xcc
> spin_dump+0x84/0xa8
> do_raw_spin_lock+0xd0/0x108
> _raw_spin_lock+0x20/0x30
> free_huge_page+0x9c/0x260
> __put_compound_page+0x44/0x50
> __put_page+0x2c/0x60
> alloc_surplus_huge_page.constprop.19+0xf0/0x140
> hugetlb_acct_memory+0x104/0x378
> hugetlb_reserve_pages+0xe0/0x250
> hugetlbfs_file_mmap+0xc0/0x140
> mmap_region+0x3e8/0x5b0
> do_mmap+0x280/0x460
> vm_mmap_pgoff+0xf4/0x128
> ksys_mmap_pgoff+0xb4/0x258
> __arm64_sys_mmap+0x34/0x48
> el0_svc_common+0x78/0x130
> el0_svc_handler+0x38/0x78
> el0_svc+0x8/0xc
>
> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
> Signed-off-by: Kai Shen <[email protected]>
> Signed-off-by: Feilong Lin <[email protected]>
> Reported-by: Wang Wang <[email protected]>
> Acked-by: Michal Hocko <[email protected]>
Good catch. Sorry, for the late reply.
Reviewed-by: Mike Kravetz <[email protected]>
--
Mike Kravetz
On Mon 06-05-19 23:22:08, Zhiqiang Liu wrote:
[...]
> Does adding Cc: stable mean adding Cc: <[email protected]>
> tag in the patch or Ccing [email protected] when sending the new mail?
The former. See Documentation/process/stable-kernel-rules.rst for more.
Thanks!
--
Michal Hocko
SUSE Labs
> On Mon 06-05-19 23:22:08, Zhiqiang Liu wrote:
> [...]
>> Does adding Cc: stable mean adding Cc: <[email protected]>
>> tag in the patch or Ccing [email protected] when sending the new mail?
>
> The former. See Documentation/process/stable-kernel-rules.rst for more.
>
> Thanks!
Thank you, Oscar Salvador and Mike Kravetz again.
>
> On 5/6/19 7:06 AM, Zhiqiang Liu wrote:
>> From: Kai Shen <[email protected]>
>>
>> spinlock recursion happened when do LTP test:
>> #!/bin/bash
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>> ./runltp -p -f hugetlb &
>>
>> The dtor returned by get_compound_page_dtor in __put_compound_page
>> may be the function of free_huge_page which will lock the hugetlb_lock,
>> so don't put_page in lock of hugetlb_lock.
>>
>> BUG: spinlock recursion on CPU#0, hugemmap05/1079
>> lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
>> Call trace:
>> dump_backtrace+0x0/0x198
>> show_stack+0x24/0x30
>> dump_stack+0xa4/0xcc
>> spin_dump+0x84/0xa8
>> do_raw_spin_lock+0xd0/0x108
>> _raw_spin_lock+0x20/0x30
>> free_huge_page+0x9c/0x260
>> __put_compound_page+0x44/0x50
>> __put_page+0x2c/0x60
>> alloc_surplus_huge_page.constprop.19+0xf0/0x140
>> hugetlb_acct_memory+0x104/0x378
>> hugetlb_reserve_pages+0xe0/0x250
>> hugetlbfs_file_mmap+0xc0/0x140
>> mmap_region+0x3e8/0x5b0
>> do_mmap+0x280/0x460
>> vm_mmap_pgoff+0xf4/0x128
>> ksys_mmap_pgoff+0xb4/0x258
>> __arm64_sys_mmap+0x34/0x48
>> el0_svc_common+0x78/0x130
>> el0_svc_handler+0x38/0x78
>> el0_svc+0x8/0xc
>>
>> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
>> Signed-off-by: Kai Shen <[email protected]>
>> Signed-off-by: Feilong Lin <[email protected]>
>> Reported-by: Wang Wang <[email protected]>
>> Acked-by: Michal Hocko <[email protected]>
>
> Good catch. Sorry, for the late reply.
>
> Reviewed-by: Mike Kravetz <[email protected]>
>
Thank your for the reply.
Friendly ping ...
On Mon, 6 May 2019 22:06:38 +0800 Zhiqiang Liu <[email protected]> wrote:
> From: Kai Shen <[email protected]>
>
> spinlock recursion happened when do LTP test:
> #!/bin/bash
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
>
> The dtor returned by get_compound_page_dtor in __put_compound_page
> may be the function of free_huge_page which will lock the hugetlb_lock,
> so don't put_page in lock of hugetlb_lock.
>
> BUG: spinlock recursion on CPU#0, hugemmap05/1079
> lock: hugetlb_lock+0x0/0x18, .magic: dead4ead, .owner: hugemmap05/1079, .owner_cpu: 0
> Call trace:
> dump_backtrace+0x0/0x198
> show_stack+0x24/0x30
> dump_stack+0xa4/0xcc
> spin_dump+0x84/0xa8
> do_raw_spin_lock+0xd0/0x108
> _raw_spin_lock+0x20/0x30
> free_huge_page+0x9c/0x260
> __put_compound_page+0x44/0x50
> __put_page+0x2c/0x60
> alloc_surplus_huge_page.constprop.19+0xf0/0x140
> hugetlb_acct_memory+0x104/0x378
> hugetlb_reserve_pages+0xe0/0x250
> hugetlbfs_file_mmap+0xc0/0x140
> mmap_region+0x3e8/0x5b0
> do_mmap+0x280/0x460
> vm_mmap_pgoff+0xf4/0x128
> ksys_mmap_pgoff+0xb4/0x258
> __arm64_sys_mmap+0x34/0x48
> el0_svc_common+0x78/0x130
> el0_svc_handler+0x38/0x78
> el0_svc+0x8/0xc
>
> Fixes: 9980d744a0 ("mm, hugetlb: get rid of surplus page accounting tricks")
> Signed-off-by: Kai Shen <[email protected]>
> Signed-off-by: Feilong Lin <[email protected]>
> Reported-by: Wang Wang <[email protected]>
> Acked-by: Michal Hocko <[email protected]>
THanks. I added cc:[email protected] to this.