linux-ext4 - Re: e2fsprogs and fast symlink

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, 24 Mar 2008 17:26:39 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Andreas Dilger <adilger@....com>
Cc:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Eric Sandeen <sandeen@...hat.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: e2fsprogs and fast symlink

On Mon, Mar 24, 2008 at 02:45:10PM -0600, Andreas Dilger wrote:
> Instead I propose that we just use the i_size itself to determine if
> there is a fast symlink, because there has never (AFAIK) been a kernel
> that created slow symlinks for files < 60 bytes in length.

I have a vague memory that at one point (along time ago, over ten
years ago) there were slow symlinks where the target was < 60 bytes.
And the kernel has always determined whether or not a symlink was fast
or slow by looking i_blocks.  (See ext3_inode_is_fast_symlink() in
fs/ext3/inode.c).

In retrospect, the true clean way to do this would have been an
explicit i_flags bitfield.  One thing we could do is make a change
into ext4 (and ext3) so that we silently set an EXT3_SLOW_LINK_FL and
EXT3_FAST_LINK_FL, and if neither is set, we fall back to a hueristic
involving i_blocks.  This gives e2fsck one more bit of redundancy to
make sure it notices problems and to make sure it gets things right.
I'm not sure it's worth it, but eventually it would allow us to clean
things up.

					- 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