FW: ibuf_empty delayed efd - openssh

This is a discussion on FW: ibuf_empty delayed efd - openssh ; > -----Original Message----- Damien Miller, 6/10/08 said: > > On Tue, 10 Jun 2008, Scott Neugroschl wrote: > > > I'm seeing something unusual in 5.0p1. Let me start by saying that > I'm > > on kind of an ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: FW: ibuf_empty delayed efd

  1. FW: ibuf_empty delayed efd


    > -----Original Message-----

    Damien Miller, 6/10/08 said:
    >
    > On Tue, 10 Jun 2008, Scott Neugroschl wrote:
    >
    > > I'm seeing something unusual in 5.0p1. Let me start by saying that

    > I'm
    > > on kind of an oddball
    > > system (HP NonStop).
    > >
    > > What I'm seeing is that at the end of an scp session, the server

    gets
    > > stuck in a loop.
    > > First I see a shutdown failure, followed by looping on an

    "ibuf_empty
    > > delayed efd 9/(0)" condition.

    >
    > I'm not sure what is going wrong here, but could you please try a
    > snapshot? We fixed a long-existing race in the efd handling @ close
    > case and the fix may serendibitously fix your case
    >

    Is this race condition check the changes in channel_register_cleanup(),
    where c->istate and c->ostate are being interrogated?

    I'd really like to avoid having to add all the changes in channel.c (the
    queueing, changed external interfaces, etc...) if I could avoid it.

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: FW: ibuf_empty delayed efd

    On Wed, 11 Jun 2008, Scott Neugroschl wrote:

    > > I'm not sure what is going wrong here, but could you please try a
    > > snapshot? We fixed a long-existing race in the efd handling @ close
    > > case and the fix may serendibitously fix your case
    > >

    > Is this race condition check the changes in channel_register_cleanup(),
    > where c->istate and c->ostate are being interrogated?
    >
    > I'd really like to avoid having to add all the changes in channel.c (the
    > queueing, changed external interfaces, etc...) if I could avoid it.


    I think this it is, though there may be other changes of relevance. It
    would probably be best if you tested a whole snapshot and then looked to
    extract specific changes if you find they work.

    -d
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. RE: FW: ibuf_empty delayed efd

    On Wednesday, June 11, 2008 Damien Miller responded
    > On Wed, 11 Jun 2008, Scott Neugroschl wrote:
    >
    > > > I'm not sure what is going wrong here, but could you please try a
    > > > snapshot? We fixed a long-existing race in the efd handling @

    close
    > > > case and the fix may serendibitously fix your case
    > > >

    > > Is this race condition check the changes in

    > channel_register_cleanup(),
    > > where c->istate and c->ostate are being interrogated?
    > >
    > > I'd really like to avoid having to add all the changes in channel.c

    > (the
    > > queueing, changed external interfaces, etc...) if I could avoid it.

    >
    > I think this it is, though there may be other changes of relevance. It
    > would probably be best if you tested a whole snapshot and then looked
    > to
    > extract specific changes if you find they work.
    >


    Found the issue. There were two, actually, one of which is fixed in the
    snapshots, and the
    other was wholly mine, and doesn't affect the mainline code.

    First issue was in do_exec_no_pty(), if USE_PIPES is not defined, the
    socketpair isn't closed after
    The dup2() calls. This is corrected in the snapshots.

    The other issue was a typo in some platform specific code I'd put into
    channel_handle_efd(),
    which caused channel_close_efd(&c->efd) not to be called.

    Corrected both these issues and Bob's your uncle!

    Thanks for the help, Damien!

    Scott


    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread