linux-ext4 - Re: [PATCH][7/28] e2fsprogs-extents.patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Feb 2008 17:09:35 -0500
From:	Theodore Tso <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH][7/28] e2fsprogs-extents.patch

On Mon, Feb 18, 2008 at 02:48:18PM -0600, Eric Sandeen wrote:
> > I think we need to get kernel patches into mainline ASAP not to set
> > the EXTENTS_FL 
> 
> You mean on devices/fifos/sockets ?  Ok.

Yes, sorry for not being explicit.

> 
> But today, with 2.6.25-rc1 and e2fsprogs-interim, long (non-fast)
> symlinks get clobbered by e2fsck, because:
> 
> Pass 1: Checking inodes, blocks, and sizes
> Inode 12 has EXTENT_FL set, but is not in extents format
> Fix? yes

Yeah, my current development branch of e2fsprogs does the right thing,
but e2fsprogs-interim doesn't.  We need to add a test to make sure
ext2fs_inode_has_valid_blocks(inode) before marking the inode bad and
asking the user if the inode should be cleared.

> and *poof* it's gone.  That one concerns me more...  This *should* be in
> extents format, right, even though it's limited to one block...

Well, for symlinks, they are only one block, so there is no reason for
it to be using the extent format.  So storing it as a single block
number makes a lot more sense.  It should just not be setting the
EXTENTS_FL flag. 

> well, if any filetypes are not supposed to have the extents flag set,
> and they're zero-length, I'd say go ahead & clear it, and even complain
> if you like - it's the design intent after all -  I wouldn't worry about
> the noise at this stage.  FWIW, I haven't seen a core dump.  :)

The current pu branch core dumps.  My development branch has at least
that problem fixed.  :-)

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html