* John Hsu (許永翰) <John.Hsu@xxxxxxxxxxxx> [230614 03:06]: > Hi Liam, thanks for your reply. Sorry, your email response with top posting is hard to follow so I will do my best to answer your questions. > > > > 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. Okay, I can have a look at 6.1.25 then. > > > 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. Right, we call mas_node_count() so that both code paths are used for preallocations and regular mas_store()/mas_store_gfp(). It shouldn't take a significant amount of time to verify there is enough nodes. > 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 check for the above reason. > > We have seen that there may be some maple_tree operations in merge_vma... If merge_vma() does anything, then there was an operation to the maple tree. > > Moreover, would maple_tree provides an API for assigning user's gfp flag for allocating node? mas_preallocate() and mas_store_gfp() has gfp flags as an argument. In your call stack, it will be called in __vma_adjust() as such: if (mas_preallocate(&mas, vma, GFP_KERNEL)) return -ENOMEM; line 715 in v6.1.25 > 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. We use GFP_KERNEL as I explained above for the VMA tree. It also will drop the lock and retry with GFP_KERNEL on failure when not using the external lock. The mmap_lock is configured as an external lock. > Allocation will not wait for reclaiming and compacting when there is no enough available memory. > Is there any concern for this design? This has been addressed above, but let me know if I missed anything here. > > > 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). Okay, I will try arm64 with v6.1.25. ... > > 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 > Thanks, Liam
