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

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

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

On Mon, Jun 16, 2008 at 9:10 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Vegard Nossum <vegard.nossum@...il.com> wrote:
>>
>> 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.

Aha. This means that I don't need to do anything but ack your fix.
Sounds good to me, thanks!

(I guess I will still need to check out -tip to find the source of the
memset redefinition warning.)


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/