Re: tty_reopen() returning -EIO because port is closing

[Grant Edwards <grant.b.edwards@gmail.com>]

On 2013-01-18, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>> If not, is it a bug in the tty layer?
>
> Our tty layer has always done this.

We'll call it a feature, then.

I don't remember ever seeing it before.  Either the test is different
(which might be), or the old non-helper tty driver would somehow cause
the open() to block/retry.

It looks like the old open() code checked to see if the port was
closing, waited for the close to finish, and then returned either
EAGAIN or ERESTARTSYS:

  // If we are in the process of closing, wait for it to complete, then return
  if (tty_hung_up_p(filp) || info->flags & ASYNC_CLOSING) 
    {
       wait_event_interruptible(info->close_wait, !(info->flags & ASYNC_CLOSING));
       return (info->flags & ASYNC_HUP_NOTIFY) ? -EAGAIN : -ERESTARTSYS;
    }

I do think I recall seeing a user-space open() block for some time
under certain circumstances.
    
>> Does Posix say than an open() may fail if it's called while another
>> process is calling close()?  IOW, is user-space code expected to retry
>> an open() call that returns EIO?  [I've never seen user-space code
>> that did that...]
>
> Interesting question. I've never liked the fact we do it (its rude to
> the userspace) but it's not clear what the correct semantics are of
> an open as a port closes, given the close must complete first
> including any drains and control changes and the open may well not
> expect to block or hang for a long time.

If my driver now behaves the same as the "standard" driver where it
didn't used to, I'm going to claim it's an improvement.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm sitting on my
                                  at               SPEED QUEEN ... To me,
                              gmail.com            it's ENJOYABLE ... I'm WARM
                                                   ... I'm VIBRATORY ...