lkml.org 
[lkml]   [2006]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] sector_t overflow in block layer
From
Date
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/

\
 
 \ /
  Last update: 2006-05-19 23:08    [W:0.077 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site