lkml.org 
[lkml]   [2021]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2021-05-02 20:15    [W:0.034 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site