Re: [PATCH] sector_t overflow in block layer

Hi,

On Fri, 2006-05-19 at 13:11 -0700, Andrew Morton wrote:

> btw, it seems odd to me that we're trying to handle the
> device-too-large-for-sector_t problem at the submit_bh() level.  What
> happens if someone uses submit_bio()?

The initial code we were trying to protect was the 

	bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);

in submit_bh(), which can take a blocknr that fits within 2^32 and
multiply it such that it overflows sector_t.  That specific case doesn't
happen for submit_bio() simply because we're already taking input
counted in sectors in that case.

So for submit_bio(), we can't do it at IO time (at least not within the
block layer.)  But...

> Isn't it something we can check at
> mount time, or partition parsing, or...?

Yes, we could and we should --- the recent ext2-devel >32-bit
discussions have already identified mount and resize as needing this
sort of attention.  It's not just for >32-bit filesystems, either --- an
existing 31-bit ext3 filesystem can be up to 8TB with 4k blocks, and
that easily exceeds the addressing limit of sector_t on 32-bit hosts
without CONFIG_LBD.

I don't think we should be doing it at partition check time.  We don't
want to unnecessarily hurt the user who created a LUN just a little
larger than 2TB and formatted a filesystem onto it that does actually
fit; or who has a <2TB filesystem, tries to lvextend it, and then finds
that the fs itself won't grow beyond 2TB.  As long as the filesystem
itself fits into sector_t we should just allow access, so it's really
mount time, not partition time, when we need to check all of this.

--Stephen