fix(exec): clean robust futex state before mm replacement (#2191)

Successful exec replaced the current address space while leaving the task's robust-list registration pointing into the old mm. A later task exit attempted to walk that stale userspace list, producing recoverable missing-VMA faults and skipping the required owner-death transition.

Take robust-list ownership exactly once and reuse one cleanup core for exit and exec. During the successful exec commit, temporarily restore the old mm, perform best-effort owner-death cleanup, and switch back to the new mm. Keep failed exec paths unchanged.

Align exec mm switching with the scheduler's active-CPU and TLB ordering. Replace raw userspace AtomicU32 operations with exception-table-protected cmpxchg implementations for x86_64, RISC-V, and LoongArch, including 32-bit sign-extension and weak LL/SC ordering requirements. Validate robust entries, preserve PI and pending metadata, use namespace-visible task IDs, and stop safely on malformed userspace state.

Defer missing-VMA diagnostics until exception-table recovery fails so expected nofault accesses do not emit misleading errors. Add exec ABI coverage for owner-death cleanup, registration reset, deterministic read-only futex faults, and early and late exec failure preservation.

Signed-off-by: longjin <longjin@dragonos.org>

Author: fslongjin

kernel/src/arch/x86_64/mm/fault.rs

@@ -347,19 +347,19 @@ impl X86_64MMArch {
                             continue;
                         }
 
-                        log::error!(
-                        "pid:{}, can not find nearest vma, \n\terror_code: {:?}, address: {:#x}, rip: {:#x}",
-                        ProcessManager::current_pid().data(),
-                        error_code,
-                        address.data(),
-                        regs.rip,
-                    );
-
-                        // VMA不存在，检查是否需要异常表修复
+                        // No VMA exists, so try an exception-table fixup first.
                         if handle_kernel_access_failed(regs) {
-                            return; // 已通过异常表修复
+                            return;
                         }
 
+                        log::error!(
+                            "pid:{}, can not find nearest vma, \n\terror_code: {:?}, address: {:#x}, rip: {:#x}",
+                            ProcessManager::current_pid().data(),
+                            error_code,
+                            address.data(),
+                            regs.rip,
+                        );
+
                         send_segv_maperr();
                         return;
                     }
@@ -469,19 +469,20 @@ impl X86_64MMArch {
                         drop(space_guard);
                         continue 'fault_retry;
                     } else {
-                        log::error!(
-                        "pid: {} No mapped vma, error_code: {:?},rip:{:#x}, address: {:#x}, flags: {:?}",
-                        ProcessManager::current_pid().data(),
-                        error_code,
-                        regs.rip,
-                        address.data(),
-                        flags
-                    );
-                        // 地址不在VMA范围内，检查是否需要异常表修复
+                        // The address is outside every VMA; try an exception-table fixup first.
                         if handle_kernel_access_failed(regs) {
-                            return; // 已通过异常表修复
+                            return;
                         }
 
+                        log::error!(
+                            "pid: {} No mapped vma, error_code: {:?},rip:{:#x}, address: {:#x}, flags: {:?}",
+                            ProcessManager::current_pid().data(),
+                            error_code,
+                            regs.rip,
+                            address.data(),
+                            flags
+                        );
+
                         send_segv_maperr();
                         return;
                     }