All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.com>
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] tty: use tty_init_dev_retry() to workaround a race condition
Date: Fri, 22 Nov 2019 10:05:09 +0100	[thread overview]
Message-ID: <eef58b47-f208-2ac5-6e02-a87f9568c70f@suse.com> (raw)
In-Reply-To: <20191121210155.limd7v6cpd5yz2e7@debian>

On 21. 11. 19, 22:01, Sudip Mukherjee wrote:
> Hi Greg,
> 
> On Thu, Nov 21, 2019 at 05:41:38PM +0100, Greg Kroah-Hartman wrote:
>> On Thu, Nov 21, 2019 at 03:22:39PM +0000, Sudip Mukherjee wrote:
>>> There seems to be a race condition in tty drivers and I could see on
>>> many boot cycles a NULL pointer dereference as tty_init_dev() tries to
>>> do 'tty->port->itty = tty' even though tty->port is NULL.
>>> 'tty->port' will be set by the driver and if the driver has not yet done
>>> it before we open the tty device we can get to this situation. By adding
>>> some extra debug prints, I noticed that:
>>>
>>> 6.650130: uart_add_one_port
>>> 6.663849: register_console
>>> 6.664846: tty_open
>>> 6.674391: tty_init_dev
>>> 6.675456: tty_port_link_device
>>>
>>> uart_add_one_port() registers the console, as soon as it registers, the
>>> userspace tries to use it and that leads to tty_open() but
>>> uart_add_one_port() has not yet done tty_port_link_device() and so
>>> tty->port is not yet configured when control reaches tty_init_dev().
>>
>> Shouldn't we do tty_port_link_device() before uart_add_one_port() to
>> remove that race?  Once you register the console, yes, tty_open() can
>> happen, so the driver had better be ready to go at that point in time.
>>
> 
> But tty_port_link_device() is done by uart_add_one_port() itself.
> After registering the console uart_add_one_port() will call
> tty_port_register_device_attr_serdev() and tty_port_link_device() is
> called from this. Thats still tty core.

Interferences of console vs tty code are ugly. Does it help to simply
put tty_port_link_device to uart_add_one_port before uart_configure_port?

thanks,
-- 
js
suse labs

  reply	other threads:[~2019-11-22  9:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-21 15:22 [PATCH v2 1/2] tty: add retry capability to tty_init_dev() Sudip Mukherjee
2019-11-21 15:22 ` [PATCH v2 2/2] tty: use tty_init_dev_retry() to workaround a race condition Sudip Mukherjee
2019-11-21 16:41   ` Greg Kroah-Hartman
2019-11-21 21:01     ` Sudip Mukherjee
2019-11-22  9:05       ` Jiri Slaby [this message]
2019-11-22  9:11         ` Jiri Slaby
2019-11-24  0:02           ` Sudip Mukherjee
2019-11-25 10:42             ` Jiri Slaby
2019-12-10 11:41         ` Sudip Mukherjee
2019-12-12 11:15           ` Greg Kroah-Hartman
2019-12-17 11:47             ` Sudip Mukherjee
2019-12-17 12:05               ` Greg Kroah-Hartman

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=eef58b47-f208-2ac5-6e02-a87f9568c70f@suse.com \
    --to=jslaby@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudipm.mukherjee@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.