public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] add module reference to struct tty_driver
Date: Tue, 14 Jan 2003 20:07:19 +0000	[thread overview]
Message-ID: <20030114200719.B4077@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20030113054708.GA3604@kroah.com>; from greg@kroah.com on Sun, Jan 12, 2003 at 09:47:09PM -0800

On Sun, Jan 12, 2003 at 09:47:09PM -0800, Greg KH wrote:
> In digging into the tty layer locking, I noticed that the tty layer
> doesn't handle module reference counting for any tty drivers.  Well, I've
> known this for a long time, just finally got around to fixing it :)
> Here's a patch against 2.5.56 that should fix this issue (works for
> me...)
> 
> Comments?  If no one objects, I'll send it on to Linus, and add support
> for this to a number of tty drivers that commonly get built as modules.

Firstly, I've proven my original suspicions about tty hangup wrong.
However, I'm concerned that we don't have sufficient locking present
(even in 2.4) to ensure that unloading tty driver modules is safe by
any means.

The first point where we obtain a driver structure is under the
BKL in tty_io.c:init_dev(), which calls get_tty_driver().
get_tty_driver() searches a list of drivers for the relevant
entry.  There are no locks here.

Now, consider tty_unregister_driver().  This is normally called from
a tty driver modules cleanup function.  Also note that there are no
locks here.

Also consider tty_register_driver() and note, again, that there are
no locks here.

Checking kernel/module.c, the BKL isn't held when calling the modules
init and cleanup functions.

So, all in all, we have a nice SMP race between loading tty driver
modules, unloading tty driver modules, and getting reference counts
on driver modules.

Since tty_register_driver() and tty_unregister_driver() are both
called from process context, the fix can be a semaphore.  However,
note carefully that any semaphore that can sleep in the open path
will drop the BKL and therefore could cause other races (wrt
driver->refcount?).

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  parent reply	other threads:[~2003-01-14 19:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-13  5:47 [RFC] add module reference to struct tty_driver Greg KH
2003-01-13  9:27 ` Russell King
2003-01-13 17:12   ` Greg KH
2003-01-13 19:51   ` Max Krasnyansky
2003-01-14 20:07 ` Russell King [this message]
2003-01-14 22:08   ` Greg KH
2003-01-15 10:00     ` Russell King
2003-01-15  9:09       ` Henrique Gobbi
2003-01-15 10:30       ` John Bradford
2003-01-15 10:40         ` Russell King
2003-01-15 11:12           ` John Bradford
2003-01-15 16:03           ` Randy.Dunlap
2003-01-15 15:26       ` Kai Germaschewski
2003-01-15 16:31       ` Roman Zippel

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=20030114200719.B4077@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --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