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

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

Message-ID: <20080822213618.GC1598@atjola.homenet>
Date:	Fri, 22 Aug 2008 23:36:18 +0200
From:	Björn Steinbrink <B.Steinbrink@....de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Junio C Hamano <gitster@...ox.com>, 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 2008.08.22 14:16:51 -0700, Andrew Morton wrote:
> It's pretty simple.  If git-bisect tells us that the regression was
> introduced by a merge commit, we want to perform a bisection within
> that merge's individual commits.

bisect already did that. It asked for the left side and the right side,
both were good. What you can still do is creating a _new_ history where
the commits are not in parallel but linearized, like Jeff described. But
that's (in general) not a trivial task as you need to reapply individual
commit patches which can cause conflicts that were already solved in the
existing merges to show up again. Or, it can even produce new conflicts,
for example when a commit on one side was reverted before the merge
happened. In that case, you get into a state with changes that were
never visible before.

Björn
--
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/