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/
>
next prev parent 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.