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: <7v7ia8ahgu.fsf@gitster.siamese.dyndns.org>
Date:	Fri, 22 Aug 2008 14:05:21 -0700
From:	Junio C Hamano <gitster@...ox.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	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

Andrew Morton <akpm@...ux-foundation.org> writes:

> On Fri, 22 Aug 2008 19:16:51 +0200
> Petr Baudis <pasky@...e.cz> wrote:
>
>> On Fri, Aug 22, 2008 at 09:25:49AM -0700, Andrew Morton wrote:
> ...
>> > urgh, it's irritating when git-bisect directs you to a merge commit - it
>> > hasn't done it for me for ages.
>> 
>> Hmm, but doesn't that happen only when it's actually really the merge
>> commit that introduces the bug? Both parents of the merge commit were
>> marked as good by the user, so...
>
> A merge commit doesn't contain any kernel changes?  It's the individual
> commits (aka "patches") which were in that merge which broke stuff. 
> Confused.
>
> We're trying to dive inside that merge commit to find out which of the
> real commits caused the regression.

You may find neither parents were buggy, but the result of the merge is.

A trivial example is when one branch changes the semantics of an existing
function and converts all the call sites to the updated semantics, while
the other branch adds a new call site that still relies on the old
behaviour of that function.  The merge most likely won't textually
conflict, and neither git merge nor quilt patch would report conflicts,
but the end result is that the new call site added by the latter branch
now gets an unexpected outcome from the function and can misbehave.  You
cannot blame the breakage to either branch for such a breakage.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ