Re: [git pull] vfs.git misc bits

[Al Viro <viro@zeniv.linux.org.uk>]

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@zeniv.linux.org.uk> 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()...