* John Hsu (許永翰) <John.Hsu@xxxxxxxxxxxx> [230609 04:37]: > Hi reviewers and author liam.howlett@xxxxxxxxxx, > 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
