Re: [git pull] work.misc

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, May 2, 2021 at 11:00 AM Matthew Wilcox <willy@infradead.org> 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