public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@google.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: Johann Lombardi <johann.lombardi@bull.net>,
	sho@tnes.nec.co.jp, cmm@us.ibm.com,
	ext2-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [RFC 1/2] ext3: enlarge blocksize and fix rec_len overflow
Date: Wed, 05 Jul 2006 11:41:08 -0700	[thread overview]
Message-ID: <44AC07C4.6030108@google.com> (raw)
In-Reply-To: <20060701083950.GB5355@schatzie.adilger.int>

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

      parent reply	other threads:[~2006-07-05 18:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-28 11:52 [RFC 1/2] ext3: enlarge blocksize and fix rec_len overflow sho
2006-06-28 15:50 ` Johann Lombardi
2006-06-28 20:24   ` Andreas Dilger
2006-06-29 10:46     ` [Ext2-devel] [RFC 1/2] ext3: enlarge blocksize and fix rec_lenoverflow Takashi Sato
2006-06-29 16:30       ` Andreas Dilger
2006-06-29 18:10     ` [RFC 1/2] ext3: enlarge blocksize and fix rec_len overflow Daniel Phillips
2006-06-29 20:27       ` Andreas Dilger
2006-06-29 22:14         ` Daniel Phillips
2006-06-30  9:31           ` Johann Lombardi
2006-06-30 18:19             ` Daniel Phillips
2006-07-01  8:39               ` Andreas Dilger
2006-07-01 10:27                 ` Michael Tokarev
2006-07-05 18:41                 ` Daniel Phillips [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44AC07C4.6030108@google.com \
    --to=phillips@google.com \
    --cc=adilger@clusterfs.com \
    --cc=cmm@us.ibm.com \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=johann.lombardi@bull.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sho@tnes.nec.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox