Re: [BUG] trigger BUG_ON in mas_store_prealloc when low memory

["John Hsu (許永翰)" <John.Hsu@mediatek.com>]

[-- Attachment #1: Type: text/plain, Size: 4210 bytes --]

Hi Liam, thanks for your reply.



version 6.1 or 6.1.x?  Which exact version (git id or version number)

Our environment is kernel-6.1.25-mainline-android14-5-gdea04bf2c398d.


This BUG_ON() is necessary since this function should _never_ run out of

memory; this function does not return an error code. mas_preallocate()

should have gotten you the memory necessary (or returned an -ENOMEM)

prior to the call to mas_store_prealloc(), so this is probably an

internal tree problem.

There is a tree operation being performed here.  mprotect is merging a

vma by the looks of the call stack.  Why do you think no tree operation

is necessary?

As you mentioned, mas_preallocate() should allocate enough node, but there is such functions mas_node_count() in mas_store_prealloc().
In mas_node_count() checks whether the *mas* has enough nodes, and allocate memory for node if there was no enough nodes in mas.
I think that if mas_preallocate() allocate enough node, why we check the node count and allocate nodes if there was no enough nodes in mas in mas_node_count()?

We have seen that there may be some maple_tree operations in merge_vma...

Moreover, would maple_tree provides an API for assigning user's gfp flag for allocating node?
In rb_tree, we allocate vma_area_struct (rb_node is in this struct.) with GFP_KERNEL, and maple_tree allocate node with GFP_NOWAIT and __GFP_NOWARN.
Allocation will not wait for reclaiming and compacting when there is no enough available memory.
Is there any concern for this design?


I see this is arm64.  Do you have a reproducer?  If you don't have a

reproducer, I can try stress-ng on amr64 to simulate your workload using

mprotect, but I need to know the exact kernel version as this issue may

have been fixed in a later stable release.

It is offen occur under low memory condiction. Maybe you can try stress-ng on arm64 under high memory stress(e.g. reserved lots of memory).

BRs,
John Hsu

internal tree problem.On Tue, 2023-06-13 at 10:11 -0400, Liam R. Howlett wrote:
External email : Please do not click links or open attachments until you have verified the sender or the content.

* John Hsu (許永翰) <John.Hsu@mediatek.com> [230609 04:37]:

> Hi reviewers and author liam.howlett@oracle.com,

> Kindly ping.

>


Hello!


Thanks for reporting this issue.


> We met BUG_ON in mas_store_prealloc with kernel-6.1 stress testing

> environment.


version 6.1 or 6.1.x?  Which exact version (git id or version number)


> According to coredump, BUG_ON is triggered by mas->node with error

> number -ENOMEM(0xffffffffffffffd2).

> There are some mas_node_count functions in mas_wr_store_entry, and it

> seems that mas->node may be set to error node with -ENOMEM if there was

> no enough memory spcace for maple tree operations.

> We think that return -ENOMEM instead of directly triggering BUG_ON when

> memory is not available is suitable,


This BUG_ON() is necessary since this function should _never_ run out of

memory; this function does not return an error code. mas_preallocate()

should have gotten you the memory necessary (or returned an -ENOMEM)

prior to the call to mas_store_prealloc(), so this is probably an

internal tree problem.


>because in reality the tree

> operation shouldn't be performed in this situation.


There is a tree operation being performed here.  mprotect is merging a

vma by the looks of the call stack.  Why do you think no tree operation

is necessary?


>

> following are the backtrace:

> mas_store_prealloc+0x23c/0x484

> vma_mas_store+0xe4/0x2d0

> __vma_adjust+0xab0/0x1470

> vma_merge+0x5b8/0x5d4

> mprotect_fixup+0x1f4/0x478

> __arm64_sys_mprotect+0x6b0/0x8f0

> invoke_syscall+0x84/0x264

> el0_svc_common+0x118/0x1f0

> do_el0_svc+0x5c/0x184

> el0_svc+0x38/0x98


I see this is arm64.  Do you have a reproducer?  If you don't have a

reproducer, I can try stress-ng on amr64 to simulate your workload using

mprotect, but I need to know the exact kernel version as this issue may

have been fixed in a later stable release.


Thanks,

Liam


[-- Attachment #2: Type: text/html, Size: 6841 bytes --]