> The point being that holding the tty lock across the _entire_ close
> is equivalent to the current outcome, regardless of O_NONBLOCK.
>
> I'm reluctant to start returning EGAIN for non-blocking tty opens
> because no tty driver does that now, and I don't think userspace will
> deal well with new
On 06/17/2014 07:03 AM, David Laight wrote:
> From: Peter Hurley
> ...
>>> I don't understand the second half of the changelog, it doesn't seem
>>> to fit here: there deadlock that we are trying to avoid here happens
>>> when the *same* tty needs the lock to complete the function that
>>> sends the
On 07/10/2014 07:09 PM, Greg Kroah-Hartman wrote:
On Mon, Jun 16, 2014 at 09:17:11AM -0400, Peter Hurley wrote:
tty_wait_until_sent_from_close() drops the tty lock while waiting
for the tty driver to finish sending previously accepted data (ie.,
data remaining in its write buffer and transmit fi
On Mon, Jun 16, 2014 at 09:17:11AM -0400, Peter Hurley wrote:
> tty_wait_until_sent_from_close() drops the tty lock while waiting
> for the tty driver to finish sending previously accepted data (ie.,
> data remaining in its write buffer and transmit fifo).
>
> However, dropping the tty lock is a h
On 06/17/2014 07:32 AM, Peter Hurley wrote:
On 06/17/2014 07:03 AM, David Laight wrote:
From: Peter Hurley
...
I don't understand the second half of the changelog, it doesn't seem
to fit here: there deadlock that we are trying to avoid here happens
when the *same* tty needs the lock to complete
> Before the patch, I believe tty_reopen() would return -EIO because
> the TTY_CLOSING flag is set. After the patch, tty_open() blocks
> on tty_lock() before calling tty_reopen(). AFAICT, this is independent
> of O_NONBLOCK.
That would be a bug then. Returning -EIO is fine (if unfriendly). The
O_N
On 06/17/2014 07:03 AM, David Laight wrote:
From: Peter Hurley
...
I don't understand the second half of the changelog, it doesn't seem
to fit here: there deadlock that we are trying to avoid here happens
when the *same* tty needs the lock to complete the function that
sends the pending data. I
On Tuesday 17 June 2014 11:03:50 David Laight wrote:
> From: Peter Hurley
> ...
> > > I don't understand the second half of the changelog, it doesn't seem
> > > to fit here: there deadlock that we are trying to avoid here happens
> > > when the *same* tty needs the lock to complete the function tha
From: Peter Hurley
...
> > I don't understand the second half of the changelog, it doesn't seem
> > to fit here: there deadlock that we are trying to avoid here happens
> > when the *same* tty needs the lock to complete the function that
> > sends the pending data. I don't think we do still do that
On 06/17/2014 04:00 AM, Arnd Bergmann wrote:
On Monday 16 June 2014 09:17:11 Peter Hurley wrote:
tty_wait_until_sent_from_close() drops the tty lock while waiting
for the tty driver to finish sending previously accepted data (ie.,
data remaining in its write buffer and transmit fifo).
However,
From: Arnd Bergmann
> On Monday 16 June 2014 09:17:11 Peter Hurley wrote:
> > tty_wait_until_sent_from_close() drops the tty lock while waiting
> > for the tty driver to finish sending previously accepted data (ie.,
> > data remaining in its write buffer and transmit fifo).
> >
> > However, droppin
On Monday 16 June 2014 09:17:11 Peter Hurley wrote:
> tty_wait_until_sent_from_close() drops the tty lock while waiting
> for the tty driver to finish sending previously accepted data (ie.,
> data remaining in its write buffer and transmit fifo).
>
> However, dropping the tty lock is a hold-over f
12 matches
Mail list logo
