> [you sounded as if you noticed a discrepancy somewhere - so I expected:
> foo.c uses this in line 123 but bar.c uses that in line 666.]
Don't always expect me to make sense - I have good days and I have bad
days. This is a bad day. Wading through the block code got me in a bad
mood, and I missed a comment as you pointed out. I didn't want to go
into that code, but I had to, to write a function to check for
out-of-range blocks. I was kind of surprised that I didn't find
anything like that already sitting around, but I can see the thinking:
blocks should never be out of range, and if they are you get a nice
clear oops. That's not very friendly to development code though. I'd
rather take control and make some sort of informative report.
Following the code in ll_rw_block.c I get:
int valid_block (struct super_block *sb, unsigned block)
{
unsigned shift = sb->s_blocksize_bits - 9, count = 1 << shift;
unsigned limit = (blk_size[MAJOR(sb->s_dev)][MINOR(sb->s_dev)] << 1) + 1;
return count <= limit && block << shift <= limit - count;
}
And I find the "+ 1" confusing. Either the blk_size is actually a
maximum and not a count or the original test:
if (maxsector < count || maxsector - count < sector)
<error>
is off by one.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
