linux-ext4 - Re: ext3: slow symlink corruption on umount...

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]

Message-ID: <20081029195403.GA8333@ajones-laptop.nbttech.com>
Date:	Wed, 29 Oct 2008 12:54:03 -0700
From:	Arthur Jones <ajones@...erbed.com>
To:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
CC:	sct@...hat.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: ext3: slow symlink corruption on umount...

This one's turning out to be a slippery fish.
I have found that the corruption appears to
be due to ->writepage() not getting called at all
for any of the long symlinks...

Ring any bells anyone?  Any ideas where to look
or what to test?  This is my first foray into
ext3 and I could definitely use some expert advice...

Arthur

On Mon, Oct 27, 2008 at 09:54:23AM -0700, Arthur Jones wrote:
> Some additional info -- and attempting to cast a wider
> net on the CC:
> 
> I do not see the long symlink corruption with mount -o data=writeback
> and we've now seen a couple cases where the symlink corruption
> does not require a umount...
> 
> Arthur
> 
> On Fri, Oct 24, 2008 at 11:37:34AM -0700, Arthur Jones wrote:
> > Hi All,  I'm seeing slow symlink corruption on ext3 on linux-2.6.27,
> > yesterday's linux-2.6 git tree and 2.6.9 RHEL4.7.  I.e. every kernel
> > I've tried I see this effect.  To reproduce this, I need:
> > 
> > * 250MB + tar file in memory (tmpfs or in the buffer cache)
> > * long symlinks in the tar file (over 60 characters)
> > * umount immediately after untarring
> > 
> > What I see is that the symlinks are corrupted, e.g.:
> > 
> > # ls -l etc/vmware-vix-disklib
> > etc/vmware-vix-disklib -> ??f
> > 
> > fsck shows:
> > 
> > Symlink /etc/vmware-vix-disklib (inode #16454) is invalid.
> > 
> > Debugfs shows:
> > 
> > debugfs:  stat <16454>
> > Inode: 16454   Type: symlink    Mode:  0777   Flags: 0x0   Generation: 1431972005
> > User:     0   Group:     0   Size: 65
> > File ACL: 0    Directory ACL: 0
> > Links: 1   Blockcount: 8
> > Fragment:  Address: 0    Number: 0    Size: 0
> > ctime: 0x4900ac69 -- Thu Oct 23 09:55:05 2008
> > atime: 0x4900ac84 -- Thu Oct 23 09:55:32 2008
> > mtime: 0x4900ac69 -- Thu Oct 23 09:55:05 2008
> > BLOCKS:
> > (0):56034
> > TOTAL: 1
> > 
> > I'm still tracking down exactly what's going on.  Anyone seen
> > anything like this before?  ext2 does not show this effect (I've
> > not tried ext4).  It happens when the backing block device is
> > a SATA drive or flash.
> > 
> > Thanks,
> > 
> > Arthur
--
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