linux-ext4 - Re: Punch hole problem on PAGE

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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1202122004490.14664@dhcp-27-109.brq.redhat.com>
Date:	Sun, 12 Feb 2012 20:09:57 +0100 (CET)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
cc:	Lukas Czerner <lczerner@...hat.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: Punch hole problem on PAGE_SIZE > blocksize

On Sun, 12 Feb 2012, Allison Henderson wrote:

> On 02/12/2012 03:31 AM, Lukas Czerner wrote:
> > On Sun, 12 Feb 2012, Allison Henderson wrote:
> > 
> > > On 02/10/2012 12:10 PM, Lukas Czerner wrote:
> > > > Hi Allison,
> > > > 
> > > > I found quite disturbing problem when testing loop discard support on
> > > > file systems where PAGE_SIZE>   blocksize. The result is that the file
> > > > system image is completely destroyed, but the underlying file system
> > > > seems ok. I have seen this messages in the logs:
> > > > 
> > > > EXT4-fs error (device sdb): ext4_ext_search_left:1221: inode #12: comm
> > > > flush-8:16: ix (2248761) != EXT_FIRST_INDEX (0) (depth 1)!
> > > > EXT4-fs (sdb): delayed block allocation failed for inode 12 at logical
> > > > offset 2258177 with max blocks 64 with error -5
> > > > EXT4-fs (sdb): This should not happen!! Data will be lost
> > > > 
> > > > and
> > > > 
> > > > EXT4-fs error (device sdd2): ext4_ext_get_blocks: inode #12: (comm
> > > > loop0) bad extent address iblock: 34479, depth: 3 pblock 0
> > > > 
> > > > Steps to reproduce
> > > > 
> > > > mkfs.ext4 -b1024 /dev/sdb
> > > > mount /dev/sdb /mnt/test2
> > > > dd if=/dev/zero of=/mnt/test2/file bs=1M count=4096
> > > > losetup /dev/loop0 /mnt/test2/file
> > > > 
> > > > cd xfstests
> > > > 
> > > > export TEST_DIR=/mnt/test
> > > > export TEST_DEV=/dev/sda
> > > > export SCRATCH_DEV=/dev/loop0
> > > > export SCRATCH_MNT=/mnt/test1
> > > > export MKFS_OPTIONS="-F -b1024"
> > > > export MOUNT_OPTIONS="-o discard"
> > > > export FSTYP="ext4"
> > > > 
> > > > while ./check 251; do echo "OK"; done
> > > > 
> > > > ..and just wait and watch the logs.
> > > > 
> > > > Do you have any idea what might be the problem ?
> > > > 
> > > > Thanks!
> > > > -Lukas
> > > > 
> > > 
> > > Hi Lukas,
> > > 
> > > Im having some trouble getting the bug to reproduce for me.  I have the
> > > dm-crypt module, but when I get to the test loop, i get "mount: unknown
> > > filesystem type 'crypto_LUKS'". Is there something else I need to do or
> > > install? With out being able to dig into it, I cant think of why it would
> > > do
> > > that, I have not seen it produce that error before.  :(   Thx!
> > > 
> > > Allison Henderson
> > 
> > Hi Allison,
> > 
> > I do not understand it either, there is no dm-crypt involved in this
> > scenario. One think that comes to my mind is that TEST_DEV (in my case
> > /dev/sda) needs to contain valid file system, but that is just how
> > xfstests works. Please, let me know if you still have problems
> > reproducing it.
> > 
> > Thanks!
> > -Lukas
> > 
> Ok, I got it, it was my fault I had forgotten that I had used the scratch
> partition for an encryption test a while back.  Sorry!  I am getting a "[not
> run] FSTRIM is not supported" though, I think I need a device that supports
> discard.  I will poke around Monday and see if I can borrow one from somebody.
> 
> Allison Henderson

Well, you'll have to try that on the recent upstream kernel, or at least
the one which has my loop discard support patch
dfaa2ef68e80c378e610e3c8c536f1c239e8d3ef
so we convert the discard command in the loop driver into punch hole to
the backing file. But I have been able to reproduce it just with dd and
fallocate - just create a file with some extents and then puch a hole in
the size of the file and you'll get the error. I believe that there is
some kind of off-by-one error (probabaly blocks count vs. block
number:)). I have not had time to investigate this issue, but I'll look
into it soon.

Thanks!
-Lukas
--
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