linux-kernel - Re: ext4 ioctl(FIEMAP) bug? observed in 2.6.29.4 (32-bit x86)

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: <20090803074554.GA21042@skywalker>
Date:	Mon, 3 Aug 2009 13:15:54 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Mark Lord <lkml@....ca>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-ext4@...r.kernel.org
Subject: Re: ext4 ioctl(FIEMAP) bug? observed in 2.6.29.4 (32-bit x86)

On Sun, Aug 02, 2009 at 05:35:24PM -0400, Mark Lord wrote:
> I have been stressing out the FIEMAP ioctl() quite a bit recently,
> while working on the wiper.sh SSD TRIM utility (part of the hdparm package).
>
> For an hour or so today, things got very confusing.
> My wiper.sh script stopped working correctly, and I narrowed
> it down to FIEMAP's incorrect use of the "LAST" flag.
>
> Normally, FIEMAP signals the final extent of a file by
> setting the "LAST" bit (bit-0) in flags.
> When the application sees this flag, it knows it should
> not need to issue any more FIEMAP calls.
>
> But suddenly, for a couple of hours today, FIEMAP began
> setting the "LAST" flag on every single FIEMAP call,
> tricking my code into thinking that the file being
> queried was a lot smaller than it really was.
>
> No strace(), because I still hadn't figured-out what was going on,
> but I did save this trace from debug code inside hdparm.
>
> The file being FIEMAP'd was a 50GB+ file, filling the ext4
> filesystem to near 100% capacity.  I have no idea what caused
> FIEMAP to misbehave, but after a couple of hours it suddenly
> started working correctly again.
>
> This was all observed on 32-bit x86 Linux-2.6.29.4,
> and no, it is not reproduceable.
>
> A command-line "sync" was done before the file was
> opened for FIEMAP.
>
> The output below shows the sequence of FIEMAP calls
> on the single massive file.  Notice that the first call
> returned the "LAST" flag set, despite there being many
> many more extents after that bunch.
>

Can you try with

commit c9877b205f6ce7943bb95281342f4001cc1c00ec
Author: Eric Sandeen <sandeen@...hat.com>
Date:   Fri May 1 23:32:06 2009 -0400

    ext4: fix for fiemap last-block test

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/