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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox