linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [git pull] vfs.git misc bits
       [not found]       ` <CAHk-=wgQz8VDDxdaj3rk861Ucjzk72hJoCjZvfaeo8jCyVc_2w@mail.gmail.com>
@ 2023-02-25 18:11         ` Al Viro
       [not found]           ` <3805D9F9-FB5D-4A8A-BE4B-845DDC508441@gmail.com>
  0 siblings, 1 reply; 2+ messages in thread
From: Al Viro @ 2023-02-25 18:11 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, linux-fsdevel, linux-arch

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()...

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [git pull] vfs.git misc bits
       [not found]           ` <3805D9F9-FB5D-4A8A-BE4B-845DDC508441@gmail.com>
@ 2023-02-25 22:02             ` Al Viro
  0 siblings, 0 replies; 2+ messages in thread
From: Al Viro @ 2023-02-25 22:02 UTC (permalink / raw)
  To: Mezgani Ali; +Cc: Linus Torvalds, linux-arch, linux-fsdevel, linux-kernel

On Sat, Feb 25, 2023 at 10:21:16PM +0100, Mezgani Ali wrote:
> Hello,
> 
> 
> Please clean the mailing list from lamers.

	First of all, I'm not an admin of vger.kernel.org; Dave Miller is.
Convincing him to make the lists subscriber-only is flat-out impossible - 
the best you can hope for is a personal ban.
	With sufficient effort you might be able to convince him to block
an exceptionally unpleasant wanker from posting; please, do not take that
as an expression of doubt regarding your capacity (or, heaven forbid,
a challenge), but you are still very far from the required level of
obnoxiousness - Dave has seen much worse.
					Hope this helps,
							Al

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-02-25 22:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <Y/gxyQA+yKJECwyp@ZenIV>
     [not found] ` <CAHk-=wiPHkYmiFY_O=7MK-vbWtLEiRP90ufugj1H1QFeiLPoVw@mail.gmail.com>
     [not found]   ` <Y/mEQUfLqf8m2s/G@ZenIV>
     [not found]     ` <Y/mVP5EsmoCt9NwK@ZenIV>
     [not found]       ` <CAHk-=wgQz8VDDxdaj3rk861Ucjzk72hJoCjZvfaeo8jCyVc_2w@mail.gmail.com>
2023-02-25 18:11         ` [git pull] vfs.git misc bits Al Viro
     [not found]           ` <3805D9F9-FB5D-4A8A-BE4B-845DDC508441@gmail.com>
2023-02-25 22:02             ` Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).