[git,pull] work.misc

Pull-request

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

Message

Al Viro May 2, 2021, 1:30 a.m. UTC

Assorted stuff all over the place.  Will cause trivial conflicts in
f2fs and csky (if you've already pulled those).

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

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 80e5d1ff5d5f1ed5167a69b7c2fe86071b615f6b:

  useful constants: struct qstr for ".." (2021-04-15 22:36:45 -0400)

----------------------------------------------------------------
Al Viro (7):
      constify dentry argument of dentry_path()/dentry_path_raw()
      get rid of autofs_getpath()
      apparmor:match_mn() - constify devpath argument
      autofs: should_expire() argument is guaranteed to be positive
      whack-a-mole: kill strlen_user() (again)
      hostfs_open(): don't open-code file_dentry()
      useful constants: struct qstr for ".."

Mikulas Patocka (1):
      buffer: a small optimization in grow_buffers

 arch/csky/include/asm/uaccess.h  |  2 --
 arch/csky/lib/usercopy.c         |  2 +-
 arch/nds32/include/asm/uaccess.h |  1 -
 arch/nios2/include/asm/uaccess.h |  1 -
 arch/riscv/include/asm/uaccess.h |  1 -
 fs/autofs/autofs_i.h             |  1 +
 fs/autofs/expire.c               |  2 +-
 fs/autofs/waitq.c                | 72 +++++++++-------------------------------
 fs/buffer.c                      |  6 +---
 fs/d_path.c                      | 10 +++---
 fs/dcache.c                      |  2 ++
 fs/ext2/namei.c                  |  3 +-
 fs/ext4/namei.c                  |  3 +-
 fs/f2fs/dir.c                    |  4 +--
 fs/f2fs/namei.c                  |  3 +-
 fs/fuse/inode.c                  |  3 +-
 fs/hostfs/hostfs_kern.c          |  2 +-
 fs/nilfs2/namei.c                |  3 +-
 fs/udf/namei.c                   |  3 +-
 fs/ufs/super.c                   |  3 +-
 include/linux/dcache.h           |  5 +--
 security/apparmor/mount.c        |  4 +--
 22 files changed, 41 insertions(+), 95 deletions(-)

Comments

Linus Torvalds May 2, 2021, 4:26 p.m. UTC | #1

On Sat, May 1, 2021 at 6:30 PM Al Viro <[e-mail]> wrote:
>
> Mikulas Patocka (1):
>       buffer: a small optimization in grow_buffers

Side note: if that optimization actually matters (which I doubt), we
could just make getblk and friends take s_blocksize_bits instead of
the block size. And avoid the whole "find first bit" thing.

As it is, we end up doing odd and broken things if anybody were to
ever use a non-power-of-2 blocksize (we check that it's a multiple of
the hw blocksize, we check that it's between 512 and PAGE_SIZE, but we
don't seem to check that it's a power-of-2).

This is mostly a legacy interface, I don't think anybody cares, but I
thought I'd mention it anyway..

                Linus

Matthew Wilcox May 2, 2021, 5:59 p.m. UTC | #2

On Sun, May 02, 2021 at 09:26:26AM -0700, Linus Torvalds wrote:
> On Sat, May 1, 2021 at 6:30 PM Al Viro <[e-mail]> wrote:
> >
> > Mikulas Patocka (1):
> >       buffer: a small optimization in grow_buffers
> 
> Side note: if that optimization actually matters (which I doubt), we
> could just make getblk and friends take s_blocksize_bits instead of
> the block size. And avoid the whole "find first bit" thing.
> 
> As it is, we end up doing odd and broken things if anybody were to
> ever use a non-power-of-2 blocksize (we check that it's a multiple of
> the hw blocksize, we check that it's between 512 and PAGE_SIZE, but we
> don't seem to check that it's a power-of-2).

I think we have checks that the hw blocksize is a power-of-two (maybe
just in SCSI?  see sd_read_capacity())

I don't see much demand in the storage industry for non-power-of-two
sizes; I was once asked about a 12kB sector size at Intel, but when I
said "no", they didn't seem surprised.  I see interest in going smaller
(cacheline sized) for pmem and I see interest in going larger (16kB
sector sizes) for NAND.

Linus Torvalds May 2, 2021, 6:14 p.m. UTC | #3

On Sun, May 2, 2021 at 11:00 AM Matthew Wilcox <[e-mail]> wrote:
>
> I think we have checks that the hw blocksize is a power-of-two (maybe
> just in SCSI?  see sd_read_capacity())

Not the hardware block size: our own fs/buffer.c block size.

I could imagine some fs corruption that causes a filesystem to ask for
something like a 1536-byte block size, and I don't see __bread() for
example checking that 'size' is actually a power of 2.

And if it isn't a power of two, then I see __find_get_block() and
__getblk_slow() doing insane things and possibly even overflowing the
allocated page.

Some filesystems actually start from the blocksize on disk (xfs looks
to do that), and do things like

        sb->s_blocksize = mp->m_sb.sb_blocksize;
        sb->s_blocksize_bits = ffs(sb->s_blocksize) - 1;

and just imagine what happens if the blocksize on disk is 1536... Now,
xfs has a check in the SB validation routine:

            sbp->sb_blocksize != (1 << sbp->sb_blocklog)

and if that fails, it will return -EFSCORRUPTED. But what about other
random filesystems?

Hopefully everybody checks it. But my point is, that passing in "size"
instead of "bits" not only caused this ffs() optimization, it's also a
potential source of subtle problems..

(But it goes back to the dark ages, I'm not blaming anybody but myself).

             Linus

[e-mail] May 2, 2021, 6:32 p.m. UTC | #4

The pull request you sent on Sun, 2 May 2021 01:30:42 +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/27787ba3fa4904422b3928b898d1bd3d74d98bea

Thank you!