All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Bombe <aeb@debian.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: tty_lock held during transmit wait in close: still unresolved
Date: Fri, 27 May 2011 02:41:04 +0200	[thread overview]
Message-ID: <20110527004104.GB4369@amos.fritz.box> (raw)
In-Reply-To: <20110526091726.55edf6c3@lxorguk.ukuu.org.uk>

On Thu, May 26, 2011 at 09:17:26AM +0100, Alan Cox wrote:
> > A minimalist way to trigger this issue is with a serial port that has
> > nothing attached:
> > 
> > stty -F /dev/ttyS0 crtscts
> > echo >/dev/ttyS0
> > 
> > The echo triggers a 30 second timeout on close while the driver is
> > trying to flush the newline. Another way is developing an USB device
> > with a virtual serial port and having it stop (by debugger or
> > crash/lockup)...
> > 
> > Any ideas on how to progress?
> 
> Send patches.

I would have, but I'm not exactly familiar with the tty code and I
thought messing around with the locking is probably not the most
promising way to start.

However…

> At any point you can show the code sleeps you can drop and retake the
> tty mutex either side of it, so you should be able to do that in the
> close timeout case. You may need to think about the order of locking with
> the port mutex but I suspect you can drop and retake both there.

…basically emulating the BKL semantics? Sounds more doable. I'll look
into it.

Of course that means it has to be done individually in all drivers.

> Most use of the mutex (but not quite all) could also be moved to a tty
> specific mutex fairly easily once someone has time, but that alone won't
> entirely fix your case.
> 
> Alan

-- 
Andreas Bombe

  reply	other threads:[~2011-05-27  0:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-25 23:59 tty_lock held during transmit wait in close: still unresolved Andreas Bombe
2011-05-26  7:11 ` Greg KH
2011-05-27  0:29   ` Andreas Bombe
2011-05-26  8:17 ` Alan Cox
2011-05-27  0:41   ` Andreas Bombe [this message]
2011-05-27 11:38     ` Arnd Bergmann
2011-05-27 12:11     ` Jiri Slaby
2011-05-27 13:53       ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110527004104.GB4369@amos.fritz.box \
    --to=aeb@debian.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arnd@arndb.de \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.