linux-kernel - Re: Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c

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:	Fri, 22 Aug 2008 15:48:46 -0400
From:	Jeff King <peff@...f.net>
To:	Björn Steinbrink <B.Steinbrink@....de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Petr Baudis <pasky@...e.cz>, Alan.Brunelle@...com,
	linux-kernel@...r.kernel.org, git@...r.kernel.org
Subject: Re: Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected

On Fri, Aug 22, 2008 at 09:37:30PM +0200, Björn Steinbrink wrote:

> Yep, and that's totally correct as far as bisect is concerned. The
> parents of that merge commit are:
> 88fa08f67bee1a0c765237bdac106a32872f57d2
> b1b135c8d619cb2c7045d6ee4e48375882518bb5
> 
> And Alan marked both of them as good.
> 
> So, unless Alan made a mistake during his bisection, each of the
> branches is correct, but the merge did not lead to a correct result. So
> while there were no textual conflicts, there were still incompatible
> changes regarding the code semantics and compatibility was not restored
> during the merge.

One thing that I have seen proposed (but never tried myself) is that you
can linearize the changes using "rebase -i" (or cherry-picking), and
then bisect that result. That is, given a history

A-B-C-D
 \   /
  E-F

where the merge "D" introduces the bug, you could try creating:

  A-B-C-E'-F'

and bisecting that. And you should know that C is good from your
previous bisection, but that F' probably is not, since it should be
textually the same as D (unless, of course, you had textual conflicts
during the rebase that you fixed up differently).

So in essence you are testing each of E and F, but based on the other
work. So you should be able to find the one patch that causes the
conflict. And depending on the conflict, you may get more information by
doing it the other way. I.e.,:

  A-E-F-B'-C'

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