linux-ext4 - Re: torrent hash failures since 3.9.0-rc1

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]

Date:	Tue, 12 Mar 2013 11:00:58 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	Markus Trippelsdorf <markus@...ppelsdorf.de>
Cc:	Theodore Ts'o <tytso@....edu>, Dave Jones <davej@...hat.com>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
	Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: torrent hash failures since 3.9.0-rc1

On Tue, Mar 12, 2013 at 12:12:27AM +0100, Markus Trippelsdorf wrote:
> On 2013.03.11 at 22:38 +0100, Markus Trippelsdorf wrote:
> > On 2013.03.11 at 17:18 -0400, Theodore Ts'o wrote:
> > > On Mon, Mar 11, 2013 at 09:46:25PM +0100, Markus Trippelsdorf wrote:
> > > > > BTW, I'm currently running 3.9-rc2 with some additional fixes from the
> > > > > ext4 dev branch, and I'm not able to reproduce the problem using
> > > > > rtorrent on my laptop.  How reliably is it reproducing for you?  Are
> > > > > you seeing the problem every time you try this?
> > > > 
> > > > Yes, it's 100% reproducible for me. If I boot a 3.8 kernel the issue
> > > > vanishes.
> > > 
> > > Would you be willing to try an experiment? 
> > > 
> > > Try pulling down the master branch from the ext4 git tree here:
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> > > 
> > > This contains all of the ext4 changes which are in 3.9-rc1, based on
> > > top of 3.8-rc3.  See if it reproduces there.  If it does, then it
> > > would tend to confirm the hypothesis that the issue was introduced by
> > > one of the ext4 patches that we merged during the 3.9-rc1 merge
> > > window... and then, since if you can reproduce the problem, if you
> > > could do a git bisect to find the guilty commit, that would really
> > > greatly appreciated.
> > > 
> > > If you can't reproduce it from the ext4.git tree, then the problem is
> > > probably caused by some other change that was introduced between 3.8
> > > and 3.9-rc1.
> > 
> > I've started a full bisection from v3.8 to todays git tree. It will take
> > ~13 steps. However it's already late here in Germany. I will continue
> > the bisection tomorrow and report back.
> 
> The issue started with:
> 
> 74cd15cd02708c7188581f279f33a98b2ae8d322 is the first bad commit
> commit 74cd15cd02708c7188581f279f33a98b2ae8d322
> Author: Zheng Liu <wenqing.lz@...bao.com>
> Date:   Mon Feb 18 00:32:55 2013 -0500
> 
>     ext4: reclaim extents from extent status tree
> 
> Please note that my local rtorrent version was configured with
> "--with-posix-fallocate". I'm not sure if distributions also enable this
> flag, but it could explain why Ted and Dave weren't able to reproduce
> the problem so far.

Hi Markus,

Thanks for reporting this problem.  My deepest apologies.

As Ted suggested, could you please try to use ext4 git tree?  I want to
make sure whether this bug has been fixed by my lastest patch series or
not.

Thanks in advance,
                                                - Zheng
--
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