[lkml]   [2009]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Regression] kdesu broken
> > 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.
> Alan, he got that idea from me.
> We don't do regressions. If user space depended on old behavior, we don't
> change behavior

I think there are two bugs being confused here. The first kdesu bug isn't
the EIO one. It's just busted userspace code that happened to be lucky.
It's also impossible to keep that "luck" going. The other problem is the
EIO - which is a bug.

> And regardless of that, I do not think EIO is the right thing to return at
> all. If the other side of a pty went away, return 0 and possibly send a
> HUP, or whatever. What did we do before?

If the other side of a pty goes away we send SIGHUP and at that point
return -EIO as required by POSIX, SuS and various other things. You
cannot return "EOF" as that means the user caused an EOF event (eg hit

There is a bug going on here (the one that bites emacs meta-whatever
compile) where you get an -EIO and that seems to be timing related due to
flushing. I'm currently working on that one. I suspect we will need to
make the close on the writer wait for the data to be flushed through the
reader side and I'm testing some fixes for that.

So there are two things here that need not to be muddled up:

1. Case where kdesu from logging what is going on and code
inspection does:

not what I wanted
discard the lot
oh damn I missed the bit I wanted

If we go back to the old pty approach we break ppp, locking rules and
everything else, and re-introduce DoS attacks (and some worse ones) going
back to 2.0 if not earlier.

2. A case where previously it happened that

write(pty, "Wibble", 6);

would *usually* block on close until the "Wibble" was consumed the
other end. (ie logically speaking the buffering is on the writer
not the reader)

We can implement that (although probably a timeout to avoid
certain deadlocks is needed)

I plan to fix #2 but not #1. There really isn't any way to keep #1 true.
Although the spec has nothing to say about #2 every implementation I've
you get the wibble reliably and we used to, so it needs fixing.


 \ /
  Last update: 2009-07-25 13:51    [W:0.152 / U:1.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site