| 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
| ||
|
Date: Sat, 5 Jan 2008 19:15:52 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org> Cc: bugme-daemon@...zilla.kernel.org, h.judt@....at Subject: Re: [Bug 9692] New: journal_data mount option causes filesystem corruption with blocksize != 4096 On Sat, 5 Jan 2008 09:52:15 -0800 (PST) bugme-daemon@...zilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9692 > > Summary: journal_data mount option causes filesystem corruption > with blocksize != 4096 > Product: File System > Version: 2.5 > KernelVersion: 2.6.23.9 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: high > Priority: P1 > Component: ext3 > AssignedTo: akpm@...l.org > ReportedBy: h.judt@....at > > > Most recent kernel where this bug did not occur: - > Older kernels have this problem too (I think I noticed this booting >= 2.6.21, > definitely 2.6.22). I'm getting the feeling that we should just disable data=journal. Make it use data=ordered mode instead. It isn't getting a lot of attention.. > Distribution: Gentoo Linux x86 > This bug seems to be hardware-independent (tested on three different machines > which all use quite different drivers). If you need hardware information or any > other log or configuration files, let me know please. > > Problem Description: > When creating an ext3 filesystem with journal_data option and block sizes > different than 4096 (tested: 1024, 2048) filesystem corruption will occur if > certain operations are performed (see below). > Corruption will not occur if 4096 block size is used, or if any other block > size is used together with journal_data_ordered or journal_data_writeback. > No errors in dmesg. > > Steps to reproduce: > I found this bug using an audio file tagger, so you need exfalso which is part > of quodlibet (http://www.sacredchao.net/quodlibet/). No other file tagger I > used produced this kind of problem. Still, this has to be a kernel problem, > right?? > > 1. Create ext3 file system: > mkfs.ext3 -O has_journal,dir_index -b 1024 /dev/sdd1 > tune2fs -c 0 -i 0 -m 0 -o journal_data /dev/sdd1 > > tune2fs 1.40.3 (05-Dec-2007) (filtered) > Filesystem volume name: <none> > Last mounted on: <not available> > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal resize_inode dir_index filetype > sparse_super > Filesystem flags: signed directory hash > Default mount options: journal_data > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 126976 > Block count: 1012060 > Reserved block count: 0 > Free blocks: 976865 > Free inodes: 126965 > First block: 1 > Block size: 1024 > Fragment size: 1024 > Reserved GDT blocks: 256 > Blocks per group: 8192 > Fragments per group: 8192 > Inodes per group: 1024 > Inode blocks per group: 128 > Last mount time: n/a > Mount count: 0 > Maximum mount count: -1 > Check interval: 0 (<none>) > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 128 > Journal inode: 8 > Default directory hash: tea > Journal backup: inode blocks > > 2. Mount it and copy mp3,ogg,... files to it. This does not cause any file > system corruption (which you can confirm by running fsck). > > pmount /dev/sdd1: > /dev/sdd1 on /media/sdd1 type ext3 (rw,noexec,nosuid,nodev,errors=continue) > > 3. Use quodlibet/exfalso to change the id3 tags. Add tags to it if not present, > or delete them if already present. This will lead to file system corruption. > > brw-r----- 1 root disk 8, 49 /dev/sdd1 > > 4. Unmount the volume. > pumount /dev/sdd1 > > 5. Run fsck -fvD /dev/sdd1. It will complain about wrong i_size. > > e2fsck 1.40.3 (05-Dec-2007) > Pass 1: Checking inodes, blocks, and sizes > Inode 47106, i_size is 5015509, should be 5017600. Fix<y>? yes > Inode 47107, i_size is 4657736, should be 4661248. Fix<y>? yes > Inode 47109, i_size is 11928555, should be 11931648. Fix<y>? yes > Inode 47111, i_size is 5698454, should be 5701632. Fix<y>? yes > Inode 47112, i_size is 9384018, should be 9388032. Fix<y>? yes > Inode 47114, i_size is 5679228, should be 5681152. Fix<y>? yes > Inode 47115, i_size is 6107218, should be 6111232. Fix<y>? yes > Inode 47117, i_size is 4354297, should be 4358144. Fix<y>? yes > Inode 47118, i_size is 4512286, should be 4513792. Fix<y>? yes > Inode 47120, i_size is 7010846, should be 7012352. Fix<y>? yes > > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 3A: Optimizing directories > Pass 4: Checking reference counts > Pass 5: Checking group summary information > > /dev/sdd1: ***** FILE SYSTEM WAS MODIFIED ***** > > 28 inodes used (0.02%) > 14 non-contiguous inodes (50.0%) > # of inodes with ind/dind/tind blocks: 15/15/0 > 123417 blocks used (12.19%) > 0 bad blocks > 0 large files > > 16 regular files > 3 directories > 0 character device files > 0 block device files > 0 fifos > 0 links > 0 symbolic links (0 fast symbolic links) > 0 sockets > -------- > 19 files > > Reproducible: Always. > No binary modules were loaded, clean boot from vanilla kernel. But of course, > also happens with gentoo-sources and tuxonice-sources and nvidia binary loaded > ;-). > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. - 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
Powered by blists - more mailing lists