lkml.org 
[lkml]   [2009]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    ^D).

    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:

    read
    not what I wanted
    discard the lot
    read
    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);
    close(pty);

    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.

    Alan


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