All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Paul Mackerras <paulus@samba.org>
Cc: torvalds@osdl.org, akpm@osdl.org, dwmw2@redhat.com,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Remove race between con_open and con_close
Date: Sun, 28 Aug 2005 07:56:40 +0800	[thread overview]
Message-ID: <4310FDB8.2040203@gmail.com> (raw)
In-Reply-To: <17168.63953.95070.579096@cargo.ozlabs.ibm.com>

Paul Mackerras wrote:
> I have a laptop (G3 powerbook) which will pretty reliably hit a race
> between con_open and con_close late in the boot process and oops in
> vt_ioctl due to tty->driver_data being NULL.
> 
> What happens is this: process A opens /dev/tty6; it comes into
> con_open() (drivers/char/vt.c) and assign a non-NULL value to
> tty->driver_data.  Then process A closes that and concurrently process
> B opens /dev/tty6.  Process A gets through con_close() and clears
> tty->driver_data, since tty->count == 1.  However, before process A
> can decrement tty->count, we switch to process B (e.g. at the
> down(&tty_sem) call at drivers/char/tty_io.c line 1626).
> 
> So process B gets to run and comes into con_open with tty->count == 2,
> as tty->count is incremented (in init_dev) before con_open is called.
> Because tty->count != 1, we don't set tty->driver_data.  Then when the
> process tries to do anything with that fd, it oopses.
> 
> The simple and effective fix for this is to test tty->driver_data
> rather than tty->count in con_open.  The testing and setting of
> tty->driver_data is serialized with respect to the clearing of
> tty->driver_data in con_close by the console_sem.  We can't get a
> situation where con_open sees tty->driver_data != NULL and then
> con_close on a different fd clears tty->driver_data, because
> tty->count is incremented before con_open is called.  Thus this patch
> eliminates the race, and in fact with this patch my laptop doesn't
> oops.
> 
> Could this go into 2.6.13 please?

I agree this should go to 2.6.13.  Though you've been beaten to the punch
by Steven Rostedt.  This is already in the mm tree.

http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2

Tony

> 
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> 
> diff -urN linux-2.6/drivers/char/vt.c pmac-2.6/drivers/char/vt.c
> --- linux-2.6/drivers/char/vt.c	2005-07-17 10:59:52.000000000 +1000
> +++ pmac-2.6/drivers/char/vt.c	2005-08-27 22:59:36.000000000 +1000
> @@ -2433,7 +2433,7 @@
>  	int ret = 0;
>  
>  	acquire_console_sem();
> -	if (tty->count == 1) {
> +	if (tty->driver_data == NULL) {
>  		ret = vc_allocate(currcons);
>  		if (ret == 0) {
>  			struct vc_data *vc = vc_cons[currcons].d;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2005-08-27 23:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-27 23:40 [PATCH] Remove race between con_open and con_close Paul Mackerras
2005-08-27 23:56 ` Antonino A. Daplas [this message]
2005-08-27 23:58 ` Russell King
2005-08-28  0:41   ` Paul Mackerras

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=4310FDB8.2040203@gmail.com \
    --to=adaplas@gmail.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dwmw2@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=torvalds@osdl.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 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.