linux-kernel - Re: Slow DOWN, please!!!

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:	Wed, 30 Apr 2008 15:51:49 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mingo@...e.hu
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	rjw@...k.pl, linux-kernel@...r.kernel.org, jirislaby@...il.com,
	tglx@...utronix.de
Subject: Re: Slow DOWN, please!!!

From: Ingo Molnar <mingo@...e.hu>
Date: Thu, 1 May 2008 00:35:09 +0200

> 
> * Ingo Molnar <mingo@...e.hu> wrote:
> 
> > What we need is not 'negative reinforcement'. That is just nasty, open 
> > warfare between isolated parties, expressed in a politically correct 
> > way.
> 
> in more detail: any "negative reinforcement" should be on the 
> _technical_ level, i.e. when changes are handled - not at the broad tree 
> level.

Sure, and I'll provide some right here.

Ingo, let me know what I need to do to change your behavior in
situations like the one I'm about to describe, ok?

Today, you merged in this bogus "regression fix".

commit ae3a0064e6d69068b1c9fd075095da062430bda9
Author: Ingo Molnar <mingo@...e.hu>
Date:   Wed Apr 30 00:15:31 2008 +0200

    inlining: do not allow gcc below version 4 to optimize inlining

    fix the condition to match intention: always use the old inlining
    behavior on all gcc versions below 4.

    this should solve the UML build problem.

    Signed-off-by: Ingo Molnar <mingo@...e.hu>
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

Did you actually read the UML build failure report?

Adrian Bunk specifically stated that the UML build failure regression
occurs with GCC version 4.3

Next, did you test this regression fix?

Next, if you could not test this regression fix, did you wait
patiently for the bug reporter to validate your fix?  Adrian
responded that it didn't fix the problem, but that was after
you queued this up to Linus already.

This proves my main beef with you Ingo.  You're way too trigger happy,
you merge things in too quickly, without checks and without
verifications.

To an arbitrary person reading the commit logs, the above
looks like you fixed something, when you actually didn't fix
anything.

And let's address this specific inlining optimization and all the
fallout it's generating.  You said you merged this thing in because
you didn't want to "wait a year for such a useful feature."  In
hindsight, that's exactly what we should have done, waited until we
could sort out all of these issues.  Yes, even if it would take a
year.

Now we're forced to sort it out somehow, unless you can get beyond
your pride and revert the original change.
--
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/