Kernel crash in maple_tree during do_mmap call

[Liam R. Howlett]

* zhang fangzheng <fangzheng.zhang1003 at gmail.com> [250326 02:46]:
> Hello, maple_tree team experts,

Hello!

> Our unisoc

The internet says:

UNISOC, formerly Spreadtrum Communications, Inc., is a Chinese fabless
semiconductor company headquartered in Shanghai which produces chipsets
for mobile phones.

Is this the correct unisoc?

Are you the same person as Fangzheng Zhang <fangzheng.zhang at unisoc.com>
from "Introduce slabinfo version 2.2" ?  It is confusing because this
email address was Cc'ed on those patches..

> encountered kernel oops during the app monkey test
> on the mobile phone.

What is "monkey test"?

> The test machine is based on android15-kernel6.6.

I'm not a google employee, do you have a source repository for that?

> However, our previous test based on kernel6.6 was passed
> before upgrading it to version  kernel6.6-2025-02_r1.

Well, that narrows down the issue, but do you have a source repository
for that?  I don't work for google and have very little view in what
they have backported, etc.

Can you please bisect to the issue since you have a known good and known
bad commit?

Can you also try the upstream released kernel?

What arch is this phone?

> But I also checked the kernel6.6-2025-02_r1 upgrade code, and there was
> no relevant modification to maple_tree, so I am very confused about
> what situation would cause such a problem.

With the limited information provided, I am afraid I cannot give you
much help with this crash.  If you could point me to the source code and
decode the mab_mas_cp offset into a line number then it might help, but
really we also need a maple tree dump.

If you can reproduce this, then we can add some debug to the correct
location under the correct condition.

> Now we report the problems we encountered, hoping to get some ideas
> and suggestions from the team.

If you can provide the above code access as well as the config option,
then we can proceed in helping you find out what is going on.

> 
> The relevant call stack is as follows:
> 
> [exception_kernel_version]: Linux version
> 6.6.66-android15-8-g7dd062f011d1-dirty-ab000015-4k (kleaf at build-host)
> (Android (11368308, +pgo, +bolt, +lto, +mlgo, based on r510928) clang
> version 18.0.0 (https://android.googlesource.com/toolchain/llvm-project
> 477610d4d0d988e69dbc3fae4fe86bff3f07f2b5), LLD 18.0.0) #1 SMP PREEMPT
> Wed Mar 19 15:50:12 CST 2025
> 
> [exception_reboot_reason]: kernel_crash
> [exception_panic_reason]: Oops: Fatal exception
> [exception_time]: 2025-03-21_18-22-40
> [exception_file_info]: not-bugon
> [exception_task_id]: 29014
> [exception_task_family]: [CrRendererMain, 29014][main, 585]
> [exception_pc_symbol]: [<ffffffd0814a3754>] mab_mas_cp+0xb0/0x278
> [exception_stack_info]: [<ffffffd07bdba250>]
> get_exception_stack_info+0x11c/0x2d0 [sysdump]
> [<ffffffd07bdba654>] prepare_exception_info+0x170/0x1f0 [sysdump]
> [<ffffffd07bdbc1dc>] sysdump_panic_event+0x5c4/0x734 [sysdump]
> [<ffffffd0805179e8>] notifier_call_chain+0x90/0x174
> [<ffffffd080517e64>] atomic_notifier_call_chain+0x3c/0x60
> [<ffffffd0814b87f0>] panic+0x18c/0x37c
> [<ffffffd080452f4c>] die+0x2f8/0x308
> [<ffffffd08046c638>] __do_kernel_fault+0x274/0x2a0
> [<ffffffd0814d2864>] do_page_fault+0x94/0x48c
> [<ffffffd0814d27b4>] do_translation_fault+0x38/0x54
> [<ffffffd08046bc48>] do_mem_abort+0x58/0x118
> [<ffffffd0814bf608>] el1_abort+0x3c/0x5c
> [<ffffffd0814bf590>] el1h_64_sync_handler+0x54/0x90
> [<ffffffd080441298>] el1h_64_sync+0x68/0x6c
> [<ffffffd0814a3754>] mab_mas_cp+0xb0/0x278

This function copies data from a big node into the standard sized nodes,
so somehow we are probably overrunning the node size.  This could be
caused by a _lot_ of things, including other things overwriting the
maple tree memory (aka a bug somewhere else screwing up the data before
it is copied) - your comment about a lack of changes to the tree between
the two does point to something like that.  But it could also totally be
a maple tree bug..

> [<ffffffd0814a263c>] mas_spanning_rebalance+0x860/0xf28
> [<ffffffd08149fbc8>] mas_wr_spanning_store+0x8b0/0xa5c
> [<ffffffd08149a1cc>] mas_wr_store_entry+0x12c/0x17c
> [<ffffffd08149a538>] mas_store_prealloc+0x9c/0x1c0
> [<ffffffd080775b54>] vma_iter_store+0x64/0x74
> [<ffffffd0807765e0>] vma_merge+0x5e4/0x73c
> [<ffffffd080777b58>] mmap_region+0x8d8/0xa2c
> [<ffffffd080776f68>] do_mmap+0x3cc/0x590
> [<ffffffd080740d40>] vm_mmap_pgoff+0x1a0/0x1f8
> [<ffffffd080777d24>] ksys_mmap_pgoff+0x78/0xf4
> [<ffffffd080452430>] __arm64_sys_mmap+0x34/0x44
> [<ffffffd08045d0f4>] invoke_syscall+0x58/0x114
> [<ffffffd08045d014>] el0_svc_common+0x80/0xe0
> [<ffffffd08045cf88>] do_el0_svc+0x1c/0x28
> [<ffffffd0814bfb64>] el0_svc+0x3c/0x70
> [<ffffffd0814bfad4>] el0t_64_sync_handler+0x68/0xbc
> [<ffffffd080441588>] el0t_64_sync+0x1a8/0x1ac
> 
> -- 
> maple-tree mailing list
> maple-tree at lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/maple-tree