linux-kernel - Re: ext4 unkillable lseek.

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]

Date:	Wed, 13 Jan 2016 12:00:21 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Dave Jones <davej@...emonkey.org.uk>,
	Dmitry Monakhov <dmonakhov@...nvz.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-ext4@...r.kernel.org
Subject: Re: ext4 unkillable lseek.

On Tue, Jan 12, 2016 at 02:17:43PM -0700, Andreas Dilger wrote:
> 
> It looks like ext4_es_find_delayed_extent_range() is being called once
> for every block in the file looking for any delalloc data, which is
> pretty awful.  Checking the git history for this code, it seems it was
> fixed once upon a time in commit 14516bb7bb:
> 
>     ext4: fix suboptimal seek_{data,hole} extents traversial
> 
>     It is ridiculous practice to scan inode block by block, this technique
>     applicable only for old indirect files. This takes significant amount
>     of time for really large files. Let's reuse ext4_fiemap which already
>     traverse inode-tree in most optimal meaner.
> 
>     TESTCASE:
>     ftruncate64(fd, 0);
>     ftruncate64(fd, 1ULL << 40);
>     /* lseek will spin very long time */
>     lseek64(fd, 0, SEEK_DATA);
>     lseek64(fd, 0, SEEK_HOLE);
> 
>     Original report: https://lkml.org/lkml/2014/10/16/620
> 
>     Signed-off-by: Dmitry Monakhov <dmonakhov@...nvz.org>
>     Signed-off-by: Theodore Ts'o <tytso@....edu>
> 
> but it was later reverted in ad7fefb10 because of a problem with ext3 and
> never restored.

The relevant thread dates back to January 3, 2015 when it went
dead/dormant.  The last message from Dimitri was:

>Crap. I do not understand why I cant not reproduce this.
>I'm out of my normal dev environment for couple of days,
>so patch reverting looks reasonable.  But please add code which
>break the loop on signal because otherwise this result in DOS for huge file

We never did do that last bit, which is probably what we should do as
a short-term fix until we can debug the "fix suboptimal seek_{data,hole}
extents traversal" patch.

							- Ted