linux-kernel - Re: 2.6.19 file content corruption on ext3

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: <Pine.LNX.4.64.0612181030330.3479@woody.osdl.org>
Date:	Mon, 18 Dec 2006 10:35:05 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	Andrew Morton <akpm@...l.org>, andrei.popa@...eo.ro,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Hugh Dickins <hugh@...itas.com>,
	Florian Weimer <fw@...eb.enyo.de>,
	Marc Haber <mh+linux-kernel@...schlus.de>,
	Martin Michlmayr <tbm@...ius.com>
Subject: Re: 2.6.19 file content corruption on ext3

On Mon, 18 Dec 2006, Peter Zijlstra wrote:
> > 
> > Or maybe the WARN_ON() just points out _why_ somebody would want to do 
> > something this insane. Right now I just can't see why it's a valid thing 
> > to do.
> 
> Maybe, but I think Nick's mail here:
>   http://lkml.org/lkml/2006/12/18/59
> 
> shows a trace like that.

Sure, but I actually think that "try_to_free_buffers()" was buggy in the 
first place, shouldn't have done what it did at all (it has NO business 
clearing dirty data), and should be fixed with my other simple and clean 
patch that just removes the crap.

But sadly, Andrei said that he still saw data corruption, which implies 
that the problem had nothing to do with "try_to_free_buffers()" at all.

(On that note: Andrei - if you do test this out, I'd suggest applying my 
patch too - the one that you already tested. It won't apply cleanly on top 
of Andrew's patch, but it should be trivial to apply by hand, since you 
really just want to remove the whole "if (ret) {...}" sequence. I realize 
that it didn't make any difference for you, but applying that patch is 
probably a good idea just to remove the noise for a codepath that you 
already showed to not matter)

> I'm guessing that if we do the WARN_ON() some folks might get a lot of 
> output, perhaps WARN_ON_ONCE() ?

Well, I'd rather get lots of noise to see all the paths that can cause 
this. We've been concentrating mainly on one (try_to_free_buffers()), but 
that one was already shown not to matter or at least not to be the _whole_ 
issue, so..

		Linus
-
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/