linux-kernel - Re: open() on /dev/tty takes 30 seconds on 2.6.36

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Nov 2010 04:32:15 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Eli Billauer <eli@...lauer.co.il>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: open() on /dev/tty takes 30 seconds on 2.6.36

On Wednesday 03 November 2010, Eli Billauer wrote:
> Arnd Bergmann wrote:
> 
> > Ok, that's certainly modem-manager in the tty_release function, calling
> > uart_close, which has this code:
> >
> >         if (port->closing_wait != ASYNC_CLOSING_WAIT_NONE) {
> >                 /*
> >                  * hack: open-coded tty_wait_until_sent to avoid
> >                  * recursive tty_lock
> >                  */
> >                 long timeout = msecs_to_jiffies(port->closing_wait);
> >                 if (wait_event_interruptible_timeout(tty->write_wait,
> >                                 !tty_chars_in_buffer(tty), timeout) >= 0)
> >                         __uart_wait_until_sent(uport, timeout);
> >         }
> >
> > port->closing_wait gets initialized to 30 seconds, which fits your
> > symptom.
> >   
> I lost you here. Maybe my version is outdated? The most similar thing I 
> have is this in tty_port.c, in tty_port_close_start():
> 
>     if (test_bit(ASYNCB_INITIALIZED, &port->flags) &&
>             port->closing_wait != ASYNC_CLOSING_WAIT_NONE)
>         tty_wait_until_sent(tty, port->closing_wait);

The code I quoted is from uart_close() in drivers/serial/serial_core.c

> I put a printk on invocations of tty_wait_until_sent(), which was called 
> like crazy during bootup on behalf of tty1, and then never again after 
> boot was completed. I should point out, that during this session, all I 
> did was to wait a few minutes and then reboot the computer from the GUI 
> login console. So I never logged in. Anyhow, the ttySx ports were opened 
> and closed, the same 30 seconds delays, but no call to 
> tty_wait_until_sent() until kernel logging was stopped.

Right. The uart_close() function does not call tty_wait_until_sent,
it calls __uart_wait_until_sent directly.

> > What does "lspci -vvx" show about the
> > port? 
> It turns out, that the device, to which ttyS1-ttyS3 are attached is a 
> soft modem, which doesn't even have drivers for a 64 bits system. There 
> is no /dev/ttyS4, which is consistent with the "Couldn't register serial 
> port 0000:05:04.0: -28" message. Anyhow, I can't say I understand why 
> any serial port was allocated to this modem. But it's not like I 
> understand how it should work.
> 
> 05:04.0 Modem: ALi Corporation SmartLink SmartPCI563 56K Modem (prog-if 
> 00 [Generic])

It should actually be covered by the intel8x0m.c driver as far as I can tell,
but it's missing from the PCI IDs in that driver...

As Alan said, we need to sort out the locking though. One problem is that
we cannot just do tty_unlock/tty_lock around the sleeping call, because we
also hold &port->mutex there, which nests inside of tty_lock().

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.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/