mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@linux.intel.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Jiri Slaby <jslaby@suse.cz>,
	gregkh@suse.de, <linux-usb@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <jirislaby@gmail.com>
Subject: Re: [PATCH 1/2] USB: serial/keyspan_pda, fix potential tty NULL dereferences
Date: Mon, 28 Feb 2011 15:19:43 +0000	[thread overview]
Message-ID: <20110228151943.140546a5@bob.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1102281006560.2161-100000@iolanthe.rowland.org>

> I wonder about these changes.  Does it makes sense to add this
> checking everywhere?  A more reasonable approach might be to make
> sure that tty_port_tty_get is never called in a context where it
> could return NULL.  Or would that involve just as much effort, making
> work routines and so on check to see whether there's an open TTY
> device before doing anything else?

The tty is refcounted so it can go away at any time including on
another processor parallel to an IRQ happening.

The right way to fix it longer term is to get every tty to be using a
tty_port (which is something we are close to) and then stuff all the
physical device related properties into the tty_port so most rx paths
simply don't dereference the tty struct.

At that point the lifetime of the relevant objects is the lifetime of
the physical port which means the driver can do

	ref count = 0
		disable interrupts
		free physical port representation & associated tty_port

the locking and tty struct use on most of the irq paths can go away for
most situations (still needed for some cases like SYSRQ).

Unfortunately there is quite a lot to move including the tty buffers,
various bits of flow control, wait queues and the like. Possibly even
the termios data.

At that point we'd only need a tty reference when we actually did the
ldisc processing or in exceptional situations.

Alan

      reply	other threads:[~2011-02-28 15:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-28  9:34 Jiri Slaby
2011-02-28  9:34 ` [PATCH 2/2] USB: serial/kobil_sct, fix potential tty NULL dereference Jiri Slaby
2011-02-28 15:14 ` [PATCH 1/2] USB: serial/keyspan_pda, fix potential tty NULL dereferences Alan Stern
2011-02-28 15:19   ` 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=20110228151943.140546a5@bob.linux.org.uk \
    --to=alan@linux.intel.com \
    --cc=gregkh@suse.de \
    --cc=jirislaby@gmail.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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®