PiyushPatle26 commented on issue #20582: URL: https://github.com/apache/nuttx/issues/20582#issuecomment-6161033644
> Hi @PiyushPatle26, > > Thank you for this thorough and detailed report. The cross-hart stale TLB translation leading to post-unmap data exposure on `rv-virt:ksmp64` is a critical finding for RISC-V SMP kernel builds (`CONFIG_BUILD_KERNEL=y` + `CONFIG_SMP=y`). > > Regarding your proposed two-stage approach: > > 1. **Stage 1 (RISC-V SBI RFENCE + IPI Fallback)**: > - Addressing the immediate correctness issue directly in `arch/risc-v/src/common/riscv_addrenv_utils.c` (`riscv_unmap_pages`) makes complete sense. > - Using the standard SBI RFENCE extension (`sbi_remote_sfence_vma`) when available ensures hardware-assisted remote invalidation on S-mode systems (OpenSBI). > - For environments without SBI RFENCE or with NuttSBI, a synchronous IPI broadcast fallback will be needed to ensure remote harts execute `sfence.vma` before the unmapping thread releases physical pages back to the allocator. > > 2. **Stage 2 (Generic TLB Shootdown Contract)**: > - Establishing a generic interface (e.g. `up_tlb_shootdown(vaddr, npages)` or similar arch-contract) across SMP architectures (ARM/ARM64, x86_64, RISC-V) will prevent this class of bug across common unmapping paths (`shm`, `pgmap`, `kmap`). > > Are you currently working on a patch/PR for Stage 1, or would > Hi, thanks for the detailed feedback! I’m currently working on Stage. I plan to discuss Stage 2, the generic TLB-shootdown interface, separately once the immediate correctness issue is addressed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
