linux-ext4 - [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 30 Oct 2009 18:05:36 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards

http://bugzilla.kernel.org/show_bug.cgi?id=14354

--- Comment #157 from Linus Torvalds <torvalds@...ux-foundation.org>  2009-10-30 18:05:28 ---
On Fri, 30 Oct 2009, bugzilla-daemon@...zilla.kernel.org wrote:
> 
> Well I've been doing bisects but I'm getting skeptical of the results; 
> either my testcase isn't reliable enough or all the merges are confusing 
> git-bisect (?)  Anyway it keeps ending up on nonsensical commits.

Merges don't confuse git-bisect (lots of merges may make bisection 
slightly less _efficient_, though, because it can be impossible to find 
commits that are nicely "in the middle"), but the way bisection works, 
even a _single_ wrong "git bisect good/bad" statement can - and will - 
make bisection results go off totally in the weeds.

Bisection is designed to be efficient, which is absolutely wonderful when 
you have a 100% unambiguous bug that needs to be found in 10,000 commits. 
It's what gives us that nice log2() behavior.

But the downside of that efficiency is the same as the downside of any 
very efficient data compression with no checksum: there is absolutely zero 
redundancy. So then if even just a single bit of information (in this case 
the "good/bad" info) is wrong, the end result will not just be wrong - it 
will be _disastrously_ wrong, and you won't even be anywhere _close_ to 
the correct end result.

[ In fact, the way bisection works, if you give a single incorrect 
  bisection point, the end result will usually be close to the commit you 
  incorrectly marked, rather than the actual buggy commit you searched 
  for.

  That _can_ be used as a hint when you're unsure - when getting a clearly 
  bogus bisection result, you can look at the bisect log, and try to find 
  the first commit in the log that is close to the clearly bogus result, 
  and you might decide to re-test that commit more carefully. And then if, 
  on re-testing, it turns out that you had been wrong the first time, you 
  might be able to avoid re-doing the whole bisection thing, and instead 
  re-do the log up to the incorrect - and now fixed - entry, and continue 
  from there. ]

That said, if you end up being uncertain about the bisection points, and 
can't give more than a "95% confidence", bisection will almost inevitably 
fail. A bug that is timing-dependent can be almost impossible to bisect. 
Even if you can reliably trigger it _eventually_, you may have to test so 
long at each bisection point that bisection becomes practically useless.

        Linus

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
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