linux-kernel - Re: [RFC][PATCH] kmemcheck: divide and conquer

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:	Mon, 16 Jun 2008 09:10:00 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Vegard Nossum <vegard.nossum@...il.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] kmemcheck: divide and conquer

* Vegard Nossum <vegard.nossum@...il.com> wrote:

> For some reason, there is no <asm/irq_vectors.h> in my repository, so 
> I assume the change came from another branch. In fact, I should have 
> included <asm/hw_irq.h>, but that doesn't contain the right 
> definitions in the tip/auto-test branch.
> 
> Yep, seems to be
> 
> commit 9b7dc567d03d74a1fbae84e88949b6a60d922d82
> Author: Thomas Gleixner <tglx@...utronix.de>
> Date:   Fri May 2 20:10:09 2008 +0200
> 
>     x86: unify interrupt vector defines
> 
> I also can't seem to get the redefined warnings, so I assume that's
> also just an indirect conflict with other -tip changes.
> 
> Right now, I am reluctant to apply your fix because it means that 
> kmemcheck tree won't build as it is. In general, what's the way to 
> resolve these things? Do you have another branch, *-fixes, where these 
> fixlets can go until either of the conflicting changesets are merged 
> upstream? If so, it seems that that would be the right place for this 
> patch. Do you agree or do you have another solution? :-)

yes, i solved it the following "Git way": i did a --no-commit merge of 
the tip/x86/irq tree into the tip/kmemcheck2 branch and then 
"git-cherry-pick --no-commit"-ed the fix and thus made it a part of that 
merge commit. This way the build failure is never visible during 
bisection either.

tip/kmemcheck2 is a temporary topic tree: it contains the pull from your 
tree and i'm testing it at the moment. It will be renamed to 
tip/kmemcheck once it has passed testing.

btw., due to kmemcheck not being rebased anymore, this will work out 
just fine in the future: i can pull fixes from your tree into 
tip/kmemcheck and it will just all get sorted out by Git, despite the 
cross-merge to tip/x86/irq.

If you rebased kmemcheck i'd have to do rather difficult (and 
error-prone and harder to trust) manual merges every time you put a 
kmemcheck fix into your tree, and any breakages introduced by new 
kmemcheck fixes would not be easily bisectable either.

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