[HELP] Anomalous memory address space segmentation on x86_64 architectures running kernel versions >= 5.10 — possible race condition in CR3 register reloading during context switch?

I am writing to this board because I have encountered a phenomenon that appears, upon initial surface-level inspection, to be well within the bounds of normal operational variability but which persists across multiple isolated reproduction attempts with statistical regularity that suggests either an undiscovered edge case or a genuine bug in the scheduler's page table management logic. Specifically, while running a multi-threaded C++ application on a Linux kernel version 6.2.4 (x86_64) under heavy contention — roughly sixteen threads pinned to separate cores each performing intensive random memory access within a shared address space of approximately 16GB — I have observed occasional segmentation faults with the bizarre characteristic that SIGSEGV is raised against an unmapped address in what should be fully committed virtual memory. The crash dump points to page fault at CR2 containing a value that is clearly not any valid user-space pointer but neither is it a canonical null or a kernel-range invalidation — it looks like some hybrid construct, possibly a partially zeroed PTE entry during TLB shootdown propagation across cores. I have been tracing the possible failure modes systematically: (1) Could this be a bug in kpagecached? Unlikely, as the page is already resident and backed by an active VMA; (2) Is it a race between mprotect(PROT_NONE) on one thread and a concurrent read/write on another with TLB shootdown latency exceeding my expectations? This is plausible given that I am running on a NUMA system with 160 cores across four sockets, which introduces significant interconnect overhead for cross-core CR3 flushes; (3) Could the kernel's RCU grace period during page table modification be being shortened by an unrelated sysctl override or a

Read the logs and post your trace before asking a question that's already been answered on the forum thread from April 2019 -- there was literally an issue report opened about this with CR3 reloading during task_switch in what looks to be exactly your kernel version range. You should

If you're actually suggesting a CR3 reload race at 5.10+, either your stack is completely wrong or your reproducer is polluted by something that isn't the kernel — which, given how this thread started, I'm leaning toward the latter.

The patch window