On Wed, 12. Jun 13:27, Uladzislau Rezki wrote: > On Wed, Jun 12, 2024 at 10:00:14AM +0800, Zhaoyang Huang wrote: > > On Wed, Jun 12, 2024 at 2:16 AM Uladzislau Rezki <urezki@xxxxxxxxx> wrote: > > > > > > > > > > > Sorry to bother you again. Are there any other comments or new patch > > > > on this which block some test cases of ANDROID that only accept ACKed > > > > one on its tree. > > > > > > > I have just returned from vacation. Give me some time to review your > > > patch. Meanwhile, do you have a reproducer? So i would like to see how > > > i can trigger an issue that is in question. > > This bug arises from an system wide android test which has been > > reported by many vendors. Keep mount/unmount an erofs partition is > > supposed to be a simple reproducer. IMO, the logic defect is obvious > > enough to be found by code review. > > > Baoquan, any objection about this v4? > > Your proposal about inserting a new vmap-block based on it belongs > to, i.e. not per-this-cpu, should fix an issue. The problem is that > such way does __not__ pre-load a current CPU what is not good. > > -- > Uladzislau Rezki mediatek & oppo also have this issue based on kernel-6.6, The following call stack more clearly illustrates the issue: [] notify_die+0x4c/0x8c [] die+0x90/0x308 [] bug_handler+0x44/0xec [] brk_handler+0x90/0x110 [] do_debug_exception+0xa0/0x140 [] el1_dbg+0x54/0x70 [] el1h_64_sync_handler+0x38/0x90 [] el1h_64_sync+0x64/0x6c [] __list_del_entry_valid_or_report+0xec/0xf0 [] purge_fragmented_block+0xf0/0x104 [] _vm_unmap_aliases+0x12c/0x29c [] vm_unmap_aliases+0x18/0x28 [] change_memory_common+0x184/0x218 [] set_memory_ro+0x14/0x24 [] bpf_jit_binary_lock_ro+0x38/0x60 [] bpf_int_jit_compile+0x4b4/0x5a0 [] bpf_prog_select_runtime+0x1a8/0x24c [] bpf_prepare_filter+0x4f0/0x518 [] bpf_prog_create_from_user+0xfc/0x148 [] do_seccomp+0x2a0/0x498 [] prctl_set_seccomp+0x34/0x4c [] __arm64_sys_prctl+0x4b4/0xea0 [] invoke_syscall+0x54/0x114 [] el0_svc_common+0xa8/0xe0 [] do_el0_svc+0x18/0x28 [] el0_svc+0x34/0x68 [] el0t_64_sync_handler+0x64/0xbc [] el0t_64_sync+0x1a4/0x1ac I placed the assignment to the CPU before xa_insert. In fact, putting it afterwards wouldn’t be a problem either. I just thought this way the content of vb remains stable. With this patch, the current stability tests no longer report related issues. Hopefully it would help you. -- help you, help me, Hailong.
