lkml.org 
[lkml]   [2006]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 1/2] ext3: enlarge blocksize and fix rec_len overflow
Andreas Dilger wrote:
> On Jun 30, 2006 11:19 -0700, Daniel Phillips wrote:
>>OK, just to handle the 64K case, what is wrong with treating 0 as 64K?
>
> Hmm, good question - it's impossible to have a valid rec_len of 0 bytes.
> There would need to be some special casing in the directory handling code.
> Also, it breaks some of the directory sanity checking, and since "0" is
> a common corruption pattern it isn't great to use. We could instead use
> 0xfffc to mean 0x10000 since they are virtually the same value and the
> error checking is safe. It isn't possible to have this as a valid value.

That might be unnecessarily paranoid, a zero would be legal only with 64K
block size and then only in the first record of the block.

How about this wrapper, with associated struct field name change?

unsigned ext3_entry_len(struct ext3_dir_entry_2 *de)
{
return (le16_to_cpu(de->entry_len) ? : (1 << 16);
}

Storing will just work. In search_dirblock we don't even get extra code
because there is already a special check for zero that goes away.

Regards,

Daniel
-
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-07-05 20:45    [W:0.037 / U:3.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site