Messages in this thread | | | Date | Tue, 28 Jul 2009 17:42:13 +0100 | From | Alan Cox <> | Subject | Re: [PATCH] kdesu broken |
| |
On Tue, 28 Jul 2009 08:49:29 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Tue, 28 Jul 2009, Alan Cox wrote: > > > > Given the assumptions in emacs are wrong, low_latency fixes the real > > world cases and we are standards compliant perhaps we are trying too > > hard ? > > Alan, I really don't understand why you seem to argue _for_ bad code, and > not just fixing it. You seem to think that it's ok to leave stuff in > buffers and ignore it, just because the other end might have exited. > > That seems disingenious and stupid. Why argue for crap?
We don't ignore it. What goes in one end comes out the other after tty processing (ldisc, echo etc). Reliably. Both the EOF fix and the tty->low_latency fix cure that. [The low latency one also provides the *exact* same semantics as we had prior to 2.6.31-rc as well]
If I understand Ogawa correctly then what emacs thinks is true is quite different: Emacs thinks that
write(pty, "data", length) close(pty) exit()
will always ensure that the other end has already got the data before close() completes - or to be more exact before the parent receives SIGCLD.
Unfortunately as both ends could do
write(pty, "enough to fill all the buffers but not block") close(pty)
at the same time it doesn't strike me as a good idea because it will deadlock.
Ogawa's latest experiment is actually quite interesting which is to also run the ldisc processing off the back of the user context. Unfortunately that breaks assorted assumptions in the kernel because the close/hangup/ldisc change paths believe that if they kill the work queue for feeding data into the ldisc then the ldisc will stop receiving data. It believes that therefore the ldisc will not do things like call the write method to echo data back to a device which has gone away, which generally involves jumping through null pointers.
So to be clear: WE DO NOT LOSE DATA.
| |