On Sat, Feb 25, 2023 at 09:04:57AM -0800, Linus Torvalds wrote: > On Fri, Feb 24, 2023 at 8:57 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > Let's have it sit around for at least a few days, OK? I mean, I'm pretty > > certain that these are fixes, but they hadn't been in any public tree - > > only posted to linux-arch. At least #fixes gets picked by linux-next... > > Ack, sounds good. ... and Intel build-bot had immediately caught a breakage in microblaze. Fixed and pushed out; I've checked all architectures affected by this series, and that was the only build breakage. However, I still have no way to test it (or anything, for that matter) on microblaze - I've no userland images for it. Status right now: alpha: bug confirmed, patch fixes it. hexagon, m68k, riscv: acked by maintainer (with explicit tested-by for m68k and riscv) microblaze, openrisc, nios2: builds, no way for me to test. sparc32, sparc64, itanic: builds, preparing to test (itanic - once I resurrect the sodding space heater I hadn't tried to boot for a couple of years; no idea whether it works). parisc: builds, but maintainers say that reproducer doesn't confirm the bug in mainline. I've parisc32 box, will try to resurrect and see what's going on. No way to test parisc64 here - no hardware and qemu/pa-risc doesn't handle 64bit system emulation. Incidentally, while digging through the arch code around #PF, something's weird on csky. Not this bug (it's handled correctly there), but... looks like vm_get_page_prot(0) returns something that would *not* pass pte_present(). Which should make life wonderful for e.g. PROT_READ|PROT_WRITE mmap() + memcpy to it + PROT_NONE mprotect() + PROT_READ|PROT_WRITE mprotect(). Unless I'm seriously misunderstanding something, we have 3 mutually exclusive cases: absent PTE - no further information in it. No page at the corresponding address range, access will fault and work from scratch; pte_none() is true for those. swap PTE - page had been swapped out, access will fault, the information in the entry encodes the location in swap. is_swap_pte() is true for those. normal page - page is there, access might or might not fault due to permissions, PTE contains the page frame number. pte_present() is true for those. PROT_NONE should not yield something that looks like a swap entry. And on csky we have #define PAGE_NONE __pgprot(_PAGE_PROT_NONE) #define pte_none(pte) (!(pte_val(pte) & ~_PAGE_GLOBAL)) #define pte_present(pte) (pte_val(pte) & _PAGE_PRESENT) and arch/csky/abiv1/inc/abi/pgtable-bits.h:26:#define _PAGE_PROT_NONE _PAGE_READ arch/csky/abiv1/inc/abi/pgtable-bits.h:8:#define _PAGE_READ (1<<1) arch/csky/abiv1/inc/abi/pgtable-bits.h:14:#define _PAGE_GLOBAL (1<<6) arch/csky/abiv1/inc/abi/pgtable-bits.h:7:#define _PAGE_PRESENT (1<<0) arch/csky/abiv2/inc/abi/pgtable-bits.h:26:#define _PAGE_PROT_NONE _PAGE_WRITE arch/csky/abiv2/inc/abi/pgtable-bits.h:9:#define _PAGE_WRITE (1<<9) arch/csky/abiv2/inc/abi/pgtable-bits.h:14:#define _PAGE_GLOBAL (1<<0) arch/csky/abiv2/inc/abi/pgtable-bits.h:10:#define _PAGE_PRESENT (1<<10) IOW, on both ABI variants we have PAGE_NONE looking like a malformed swap entry. And is_swap_pte() is simply !pte_none() && !pte_present()...
