Date:	Wed, 29 Jul 2009 00:46:39 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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

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

Which is not about the emacs bug but old versions of kdesu relying upon
data boundaries happening to occur in the "right" places.

> 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.

I did not as you seem to think ever advocate not fixing the emacs problem.
Clearly we need to fix the behaviour because apps rely on it and its not
an outright "duh.." on the app side its a reasonable expectation in the
simple case.

Instead I got a whole collection of mail from you most of which indicated
you hadn't even understood the problem.

BTW: The tty->low_latency fix doesn't work, because the ->write method
can be called from an IRQ and that means we can't use ->low_latency=1 as
we take mutexes.

If you don't take the mutexes you revert the fixes that stop high speed
data sessions such as 3G Modem randomly hanging until you disconnect from
your provider and try again.

So the current state of play is
	as is breaks emacs
	revert pty changes breaks ppp, 
	tty->low_latency breaks ppp
	Ogawa's patch can lock up and races including exploitable jumps
		into freed memory
	blocking in close deadlocks if both ends get stuck that way

The best suggestion I can come up with for the new maintainer is to
implement a block in close() on the slave side only, and probably with an
interruptible wait. Set TTY_EOFPENDING when you enter close, sleep on
TTY_EOF being set when the workqueue flushing data into the ldisc
finishes shovelling. Providing exit() closes the file handles before
sending the signal that'll then give expected semantics. A pty master
close is "magic" anyway as it triggers a hangup event.

> 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.

The security exploits on 2.6.27 don't work on 2.6.30, please fix
the regression so I get root again. Get real, that is what you just
claimed and its donkey poo. There is a point at which you fix stuff and a
point at which you don't.

The thing I advocated not fixing is that in some cases kdesu fails
because some old versions at least do

	read(fd, buf, lots);
	if (buf starts with something I want) {
		while(read more data)
			look for pattern
	}

but never looks for pattern in the first read data after the start it
wanted - ie it relied upon magic happy chance buffer boundary
preservation. Thats well beyond what is sane to try and preserve unless
it is easy to do which its not.

The emacs assumption is wrong, actually always untrue for some cases
(fork, child inherits pty, parent exits for one) but worth preserving for
the cases it happens to work. I've never argued otherwise.

Alan
--
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