[git,pull] vfs.git misc bits

  Assorted stuff that didn't fit anywhere else.

That should cover the rest of what I had in -next; I'd been sick for
several weeks, so a lot of pending stuff I hoped to put into -next
is going to miss this window ;-/

Al, off to deal with the remaining pile in the mailbox...

The following changes since commit b7bfaa761d760e72a969d116517eaa12e404c262:

  Linux 6.2-rc3 (2023-01-08 11:49:43 -0600)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc

for you to fetch changes up to 39ecb653f671bbccd4a3c40f7f803f2874252f81:

  nsfs: repair kernel-doc for ns_match() (2023-01-11 15:47:40 -0500)

----------------------------------------------------------------
Fabio M. De Francesco (1):
      fs/cramfs: Convert kmap() to kmap_local_data()

Lukas Bulwahn (1):
      nsfs: repair kernel-doc for ns_match()

Thomas Weißschuh (1):
      nsfs: add compat ioctl handler

 fs/cramfs/inode.c | 9 ++++-----
 fs/nsfs.c         | 3 ++-
 2 files changed, 6 insertions(+), 6 deletions(-)
  

On Thu, Feb 23, 2023 at 7:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> That should cover the rest of what I had in -next; I'd been sick for
> several weeks, so a lot of pending stuff I hoped to put into -next
> is going to miss this window ;-/

Does that include the uaccess fixes for weird architectures?

I was hoping that was coming...

               Linus
  

The pull request you sent on Fri, 24 Feb 2023 03:40:57 +0000:

> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/489fa31ea873282b41046d412ec741f93946fc2d

Thank you!
  

On Thu, Feb 23, 2023 at 7:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc

Ugh. And I just noticed that you broke my perfect run of "only pull
signed tags" this merge window.

Oh well. It's not like it's a disaster, but it's a bit sad.

My scripting currently reacts to pulling unsigned stuff only when it's
not coming from a kernel.org tree. I think I should just update my
scripts to always alert me.

I should have realized as I pulled those anyway, but I just didn't
think about it.

              Linus
  

On Fri, Feb 24, 2023 at 07:33:12PM -0800, Linus Torvalds wrote:
> On Thu, Feb 23, 2023 at 7:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > That should cover the rest of what I had in -next; I'd been sick for
> > several weeks, so a lot of pending stuff I hoped to put into -next
> > is going to miss this window ;-/
> 
> Does that include the uaccess fixes for weird architectures?
> 
> I was hoping that was coming...

Missed -next; I'll look for tested-by/reviewed-by/etc. and put the same
patches into #fixes; we have a week until the end of merge window, and
those are fixes, after all...
  

On Sat, Feb 25, 2023 at 03:45:06AM +0000, Al Viro wrote:
> On Fri, Feb 24, 2023 at 07:33:12PM -0800, Linus Torvalds wrote:
> > On Thu, Feb 23, 2023 at 7:41 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > > That should cover the rest of what I had in -next; I'd been sick for
> > > several weeks, so a lot of pending stuff I hoped to put into -next
> > > is going to miss this window ;-/
> > 
> > Does that include the uaccess fixes for weird architectures?
> > 
> > I was hoping that was coming...
> 
> Missed -next; I'll look for tested-by/reviewed-by/etc. and put the same
> patches into #fixes; we have a week until the end of merge window, and
> those are fixes, after all...

Collected and pushed out as #fixes; exact same patches as the last time.
I hope I hadn't missed anyone's ACKs/Tested-by/whatnot...

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

Al, still crawling through bloody piles of mail - iov_iter threads, in
particular ;-/
  

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.

               Linus
  

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

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