linux-kernel - Re: [PATCH] kdesu broken

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: <alpine.LFD.2.01.0907281158120.3186@localhost.localdomain>
Date:	Tue, 28 Jul 2009 12:08:57 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Ray Lee <ray-lk@...rabbit.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] kdesu broken

On Tue, 28 Jul 2009, Alan Cox wrote:
>
> In which case you need the write to be synchronous to the ldisc
> processing. Which is what tty->low_latency = 1 did. That provides your
> required causality.
> 
> So what exactly is the problem.

The problem is that you seem to be arguing against the _nicer_ fix, that 
also makes more conceptual sense, and that doesn't even depend on the 
whole low-latency hackery.

And I don't see why you argue that.

Furthermore, you have been CONTINUALLY arguing that emacs is buggy. 
Without any logic to back that up what-so-ever. You argued that just a few 
minutes ago. 

Why? Why are you making those outlandish claims? What I'm so unhappy about 
is that your whole reaction to it - from the beginning - was to blame 
anything but the patch that caused it, and that it was bisected down to.

Why? Why blame emacs? Why call user land buggy, when the bug was 
introduced by you, and was in the kernel? Why are you fighting it? Why did 
it take so long to admit that all the regressions were kernel problems? 
Why were you trying to dismiss the regression report as a user-land bug 
from the very beginning?

Let me quote one of your first emails as I got cc'd on this thread:

    > > See the thread starting here: ("possible regression with pty.c commit")
    > >    http://lkml.org/lkml/2009/7/11/125
    > 
    > Thanks for the pointer.
    > 
    > Well, I thought we were expected to avoid breaking existing user space, even
    > if that were buggy etc.

    I don't know where you got that idea from. Avoiding breaking user space
    unneccessarily is good but if its buggy you often can't do anything about
    it.

That was you talking to Rafael, who tracks regressions, and trying to
argue that it wasn't a kernel bug (both in the double quoted thing and
in the final one).

And no, that was not a fluke. TODAY, you sent out an email saying that 
EWOUDLBLOCK/EAGAIN would be "correct". Despite me having told you that it 
_clearly_ is not correct, and despite you knowing that it breaks user 
space.

WHY?

Quite frankly, I don't understand why I should even have to bring these 
issues up. You should have tried to fix the problem immediately, without 
arguing against fixing the kernel. Without blaming user space. Without 
making idiotic excuses for bad kernel behavior.

The fact is, breaking regular user applications is simply not acceptable. 
Trying to blame kernel breakage on the app being "buggy" is not ok. And 
arguing for almost a week against fixing it - that's just crazy.

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