Messages in this thread | | | Subject | Re: [PATCH] sector_t overflow in block layer | From | "Stephen C. Tweedie" <> | Date | Fri, 19 May 2006 22:05:47 +0100 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |