Messages in this thread | | | From | Linus Torvalds <> | Date | Sun, 2 May 2021 11:14:54 -0700 | Subject | Re: [git pull] work.misc |
| |
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
| |