Re: [PATCH] sector_t overflow in block layer

[Andrew Morton <akpm@osdl.org>]

"Stephen C. Tweedie" <sct@redhat.com> wrote:
>
> Hi,
> 
> On Thu, 2006-05-18 at 17:23 -0600, Andreas Dilger wrote:
> 
> > I looked at that also, but it isn't clear from the use of "b_size" here
> > that there is any constraint that b_size is a power of two, only that it
> > is a multiple of 512.  Granted, I don't know whether there are any users
> > of such a crazy thing, but the fact that this is in bytes instead of a
> > shift made me think twice.
> 
> Yeah.  It was very strongly constrained to a power-of-two in the dim and
> distant past, when buffer_heads were only ever used for true buffer-
> cache data (the entire IO path had to be special-cased for IO that
> wasn't from the buffer cache, such as swap IO.)  
> 
> But more recently it has been a lot more relaxed, and we've had patches
> like Jens' "varyIO" patches on 2.4 which routinely generated odd-sized
> b_size buffer_heads when doing raw/direct IO on unaligned disk offsets.
> 
> But in 2.6, I _think_ such paths should be going straight to bio, not
> via submit_bh.  Direct IO certainly doesn't use bh's any more, and
> pretty much any other normal disk IO paths are page-aligned.  I might be
> missing something, though.
> 

We use various values of b_size when using a buffer_head for gathering a
disk mapping.  See, for example, fs/direct-io.c:get_more_blocks().

I don't think we ever play such tricks when a bh is used as an IO
container.  But we might - I see nothing in submit_bh() which would prevent
it.



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()?  Isn't it something we can check at
mount time, or partition parsing, or...?
-
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/