[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFQmdRbkYiOArK09smfMvf2DJ8h-bYvKyXRN_nmX-bPG8ENmjA@mail.gmail.com>
Date: Wed, 23 Nov 2011 09:58:11 -0800
From: Havard Skinnemoen <hskinnemoen@...gle.com>
To: Jiri Slaby <jslaby@...e.cz>
Cc: Dave Jones <davej@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
Jiri Slaby <jirislaby@...il.com>,
Alan Cox <alan@...ux.intel.com>
Subject: Re: tty related lockdep trace during bootup on 3.2-rc2
On Wed, Nov 23, 2011 at 2:12 AM, Jiri Slaby <jslaby@...e.cz> wrote:
> Oh, how it can be? You should vhangup the device on disconnect. Then you
> will be sure all close calls were performed before freeing the port.
> Then you can free the port, right?
>
> Like:
> * forbid further opens
> * tty_vhangup
> * stop the device
> * free the device state
Ok, interesting. It seems pretty different from what the driver is
currently doing. I'll see if I can figure out how to rework the
disconnect code.
I guess one remaining concern is that someone might still hold the
device open after hangup, so if we free the device state, which
includes the tty_port, something bad might happen, no?
> Also it looks like you have a leak in disconnect when there are users
> still. If I am looking correctly?
Funny you should say that. I'm also trying to investigate a case in
which the driver appears to leak tty devices, i.e. after a few days of
stress testing, /sys/class/tty is full of dangling ttyACMx symlinks
and new devices are ignored because acm_table is full.
Havard
--
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/
Powered by blists - more mailing lists