Hi Jordan, On 2021/02/04 10:59AM, Jordan Niethe wrote: > When adding a pte a ptesync is needed to order the update of the pte > with subsequent accesses otherwise a spurious fault may be raised. > > radix__set_pte_at() does not do this for performance gains. For > non-kernel memory this is not an issue as any faults of this kind are > corrected by the page fault handler. For kernel memory these faults are > not handled. The current solution is that there is a ptesync in > flush_cache_vmap() which should be called when mapping from the vmalloc > region. > > However, map_kernel_page() does not call flush_cache_vmap(). This is > troublesome in particular for code patching with Strict RWX on radix. In > do_patch_instruction() the page frame that contains the instruction to > be patched is mapped and then immediately patched. With no ordering or > synchronization between setting up the pte and writing to the page it is > possible for faults. > > As the code patching is done using __put_user_asm_goto() the resulting > fault is obscured - but using a normal store instead it can be seen: > > [ 418.498768][ T757] BUG: Unable to handle kernel data access on write at > 0xc008000008f24a3c > [ 418.498790][ T757] Faulting instruction address: 0xc00000000008bd74 > [ 418.498805][ T757] Oops: Kernel access of bad area, sig: 11 [#1] > [ 418.498828][ T757] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA > PowerNV > [ 418.498843][ T757] Modules linked in: nop_module(PO+) [last unloaded: > nop_module] > [ 418.498872][ T757] CPU: 4 PID: 757 Comm: sh Tainted: P O > 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 > [ 418.498936][ T757] NIP: c00000000008bd74 LR: c00000000008bd50 CTR: > c000000000025810 > [ 418.498979][ T757] REGS: c000000016f634a0 TRAP: 0300 Tainted: P > O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) > [ 418.499033][ T757] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: > 44002884 XER: 00000000 > [ 418.499084][ T757] CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: > 42000000 IRQMASK: 1 > > This results in the kind of issue reported here: > https://lore.kernel.org/linuxppc-dev/15ac5b0e-a221-4b8c-9039-fa96b8ef7...@lca.pw/ >
Thanks for fixing this! - Naveen
