mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Eli Billauer <eli@billauer.co.il>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>
Subject: Re: open() on /dev/tty takes 30 seconds on 2.6.36
Date: Wed, 3 Nov 2010 10:34:58 +0000	[thread overview]
Message-ID: <20101103103458.2f0bac8c@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <201011030432.15393.arnd@arndb.de>

> I hope Alan can figure out if it's either safe to drop both here, or if we
> might be able to call uart_close without tty_lock() held in the first place.

That was always my intention and why I moved it to tty_port. I think it
is safe to do that, but as far as I can tell the port mutex is assumed
held by the low level drivers during the uart ops calls some of the time.

Safest is probably to drop the tty lock before we take the port mutex and
take it again when we exit.

The tty_port fields are protected by the port mutex/lock

The uport methods by the uport lock

The only two points of concern I see are updating of closing_wait as it
is read (no big deal), and the nasty - which is tty_ldisc_flush. I am not
sure what assumptions lurk in the ldisc flush paths but I think it's ok.

uart_wait_until_sent will also need to not take the tty lock at that
point to fix it properly.

      reply	other threads:[~2010-11-03 10:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-30  7:47 Eli Billauer
2010-10-30 18:46 ` Andrew Morton
2010-10-30 20:46   ` Arnd Bergmann
2010-10-31  0:20   ` Eli Billauer
2010-10-31  3:36     ` Arnd Bergmann
2010-10-31  6:34       ` James Cloos
2010-10-31 11:36         ` Arnd Bergmann
2010-11-02 10:28           ` Tejun Heo
2010-11-01  1:12       ` Eli Billauer
2010-11-01 19:39         ` Arnd Bergmann
2010-11-01 20:46           ` Alan Cox
2010-11-03  0:15           ` Eli Billauer
2010-11-03  3:32             ` Arnd Bergmann
2010-11-03 10:34               ` Alan Cox [this message]

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=20101103103458.2f0bac8c@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=eli@billauer.co.il \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®