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.1506091234240.26548@localhost.localdomain>
Date:	Tue, 9 Jun 2015 12:35:15 +0200 (CEST)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	Wen Congyang <ghostwcy@...il.com>
cc:	Stefan Hajnoczi <stefanha@...il.com>,
	David Weber <wb@...zinger.de>, linux-ext4@...r.kernel.org,
	qemu-devel@...gnu.org, wenqing.lz@...bao.com
Subject: Re: [Qemu-devel] Re-2: Strange problems with lseek in qemu-img map

On Sat, 6 Jun 2015, Wen Congyang wrote:

> Date: Sat, 06 Jun 2015 11:53:50 +0800
> From: Wen Congyang <ghostwcy@...il.com>
> To: Lukáš Czerner <lczerner@...hat.com>, Stefan Hajnoczi <stefanha@...il.com>
> Cc: David Weber <wb@...zinger.de>, linux-ext4@...r.kernel.org,
>     qemu-devel@...gnu.org, wenqing.lz@...bao.com
> Subject: Re: [Qemu-devel] Re-2: Strange problems with lseek in qemu-img map
> 
> At 2015/6/5 23:14, Lukáš Czerner Wrote:
> > On Fri, 5 Jun 2015, Stefan Hajnoczi wrote:
> > 
> > > Date: Fri, 5 Jun 2015 15:05:15 +0100
> > > From: Stefan Hajnoczi <stefanha@...il.com>
> > > To: David Weber <wb@...zinger.de>
> > > Cc: qemu-devel@...gnu.org, linux-ext4@...r.kernel.org,
> > >      Lukas Czerner <lczerner@...hat.com>, wency@...fujitsu.com
> > > Subject: Re: [Qemu-devel] Re-2:  Strange problems with lseek in qemu-img
> > > map
> > > 
> > > On Wed, Jun 03, 2015 at 03:09:40PM +0000, David Weber wrote:
> > > > > > I then startet a fedora 22 live system and I saw the same problem.
> > > > > > It
> > > > > > happens
> > > > > > on both the ramdisk and a ext4 filesystem.
> > > > > 
> > > > > "it" == qemu-img map hangs or takes a very long time?
> > > > I never waited for it to complete but I guess it just takes very long.
> > > > 
> > > > > 
> > > > > Can you post a shell script that reproduces this with a ramdisk?  That
> > > > > seems like the easiest way to get people debugging it.
> > > > 
> > > > You can use the following commands.
> > > > 
> > > > mkfs.ext4 /dev/ram0
> > > > mkdir -p /mnt/tmp
> > > > mount /dev/ram0 /mnt/tmp
> > > > cd /mnt/tmp
> > > > qemu-img create test 500G
> > > > time qemu-img map test
> > > > 
> > > > This takes foreover on all my systems.
> > > 
> > > I experience the same thing on Linux 4.1.0-rc5 with ext4 (4 KB file
> > > system block size, 512B device sector size).
> > > 
> > > The lseek() calls take *seconds* to complete on a completely empty
> > > (sparse) 500G file.
> > > 
> > > Here is the perf-top(1) output:
> > > 
> > >    34.08%  [kernel]                         [k] _raw_read_lock
> > >    21.11%  [kernel]                         [k] ext4_es_lookup_extent
> > >    20.67%  [kernel]                         [k]
> > > ext4_es_find_delayed_extent_range
> > >     8.68%  [kernel]                         [k] ext4_map_blocks
> > >     4.99%  [kernel]                         [k] ext4_llseek
> > >     1.90%  [kernel]                         [k] rb_next
> > >     0.14%  [kernel]                         [k] __fget
> > > 
> > > Yikes!
> > > 
> > > The syscall causing this is just:
> > > 
> > > lseek(7, 0, SEEK_DATA)
> > > 
> > > Lukas: I've CCed you because you have helped with ext4 issues in the
> > > past.  Not sure if you have time or if this is your area.
> > > 
> > > Stefan
> > 
> > Hi,
> > 
> > this is definitely an issue with extent status tree and I have not seen
> > it before. I'll look at it first thing next week, but meanwhile I'll
> > add Zheng Liu who is the author of the extent status tree so he
> > might be able to help you.
> 
> It is an known bug, and Dmitry Monakhov tried to fix it:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=14516bb7bb6ffbd49f35389f9ece3b2045ba5815
> 
> But this patch introduced another problem, and have been reverted.
> 
> Thanks
> Wen Congyang

Wow, the code is so broken :) Luckily the fix should be fairly easy,
I am testing it now.

Thanks everyone for pointing this out.

-Lukas

> 
> > 
> > Regards,
> > -Lukas
> > 
> > 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ