On Tue, 2024-06-11 at 21:13 +0800, Leo Yu-Chi Liang wrote: > The previous reset procedure is > 1. Set direct map attribute to invalid > 2. Flush TLB > 3. Reset direct map attribute to default > > It is possible that kernel forks another process > on another core that access the invalid mappings after > sync_kernel_mappings. > > We could reproduce this scenario by running LTP/bpf_prog > multiple times on RV32 kernel on QEMU. > > Therefore, the following procedure is proposed > to avoid mappings being invalid. > 1. Reset direct map attribute to default > 2. Flush TLB Can you explain more about what is happening in this scenario? Looking briefly, riscv is doing something unique around sync_kernel_mappings(). If a RO mapping is copied instead of a NP/invalid mapping, how is the problem avoided?
