public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Mark Knecht <markknecht@gmail.com>
Cc: pavel@suse.cz, LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>
Subject: [PATCH -rt] race condition in fs/compat.c with compat_sys_ioctl
Date: Tue, 15 Nov 2005 23:29:46 -0500	[thread overview]
Message-ID: <1132115386.5047.61.camel@localhost.localdomain> (raw)
In-Reply-To: <5bdc1c8b0511141057l60a2e778x89155cd5484d532f@mail.gmail.com>

Hi Ingo and friends.

Well I finally got my AMD64 x2 up and running and a cross compiler
working (is there a better way in Debian to get a AMD64 cross compiler
than building one from scratch?).

I got Thomas' kthrt running with no problem (my default kernel in
fact ;-)

Then I felt good and compiled -rt.  After a few problems (mostly
configuration) it booted and I got the gdm login.  "cool" I thought.

Well, as soon as I logged in, the system froze.  Well not really. I had
interrupts working, and the mouse moved around, but all the bash shells
would lock up immediately, as well as all the gnome-terminals ???

Well I solved it, and this might even be a problem with the vanilla
kernel.  Grant you, this is most susceptible with a dual AMD64 on RT.

Here's the problem: 

in fs/compat.c: compat_sys_ioctl

It has this hash table of ioctl commands protected with a ioctl32_sem.
To get an ioctl you must grab the sem and then search for your ioctl in
the hash table.  When you find it, you call your ioctl and then release
the sem. 

That's the problem. I found out that one ioctl might sleep holding the
sem and won't be woken up until another process calls another ioctl to
wake it up. But unfortunately, the one waking up the sleeper will block
on the sem.  (the killer was tty_wait_until_sent)

I don't know how this doesn't lock up the non-rt kernels.  I guess the
ioctls just don't sleep. I haven't looked too deep into why this works
outside of -rt, I just solved it for -rt and will look deeper into this
tomorrow.

Here's the patch:

I created a temporary variable to hold the function pointer when it
finds the ioctl to call, and then release the semaphore.  This is
definitely the solution for -rt, since I can't login without this patch.

-- Steve

PS. There's other bug messages I'm getting (in -rt), but I'll work on
those tomorrow ;-)

Index: linux-2.6.14-rt13/fs/compat.c
===================================================================
--- linux-2.6.14-rt13.orig/fs/compat.c	2005-10-27 20:02:08.000000000 -0400
+++ linux-2.6.14-rt13/fs/compat.c	2005-11-15 23:00:14.000000000 -0500
@@ -347,6 +347,7 @@
 	int error = -EBADF;
 	struct ioctl_trans *t;
 	int fput_needed;
+	ioctl_trans_handler_t handler = NULL;
 
 	filp = fget_light(fd, &fput_needed);
 	if (!filp)
@@ -394,8 +395,11 @@
 	   this lock! -AK */
 	down_read(&ioctl32_sem);
 	for (t = ioctl32_hash_table[ioctl32_hash(cmd)]; t; t = t->next) {
-		if (t->cmd == cmd)
+		if (t->cmd == cmd) {
+			handler = t->handler;
+			up_read(&ioctl32_sem);
 			goto found_handler;
+		}
 	}
 	up_read(&ioctl32_sem);
 
@@ -413,15 +417,13 @@
 	goto out_fput;
 
  found_handler:
-	if (t->handler) {
+	if (handler) {
 		lock_kernel();
-		error = t->handler(fd, cmd, arg, filp);
+		error = handler(fd, cmd, arg, filp);
 		unlock_kernel();
-		up_read(&ioctl32_sem);
 		goto out_fput;
 	}
 
-	up_read(&ioctl32_sem);
  do_ioctl:
 	error = vfs_ioctl(filp, fd, cmd, arg);
  out_fput:



       reply	other threads:[~2005-11-16  4:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1131821278.5047.8.camel@localhost.localdomain>
     [not found] ` <5bdc1c8b0511121725u6df7ad9csb9cb56777fa6fe64@mail.gmail.com>
     [not found]   ` <Pine.LNX.4.58.0511122149020.25152@localhost.localdomain>
     [not found]     ` <5bdc1c8b0511121914v12dc4402u424fbaf416bf3710@mail.gmail.com>
     [not found]       ` <1131853456.5047.14.camel@localhost.localdomain>
     [not found]         ` <5bdc1c8b0511130634h501fb565v58906bdfae788814@mail.gmail.com>
     [not found]           ` <1131994030.5047.17.camel@localhost.localdomain>
     [not found]             ` <5bdc1c8b0511141057l60a2e778x89155cd5484d532f@mail.gmail.com>
2005-11-16  4:29               ` Steven Rostedt [this message]
2005-11-16  5:55                 ` [PATCH -rt] race condition in fs/compat.c with compat_sys_ioctl Andi Kleen
2005-11-16  8:33                   ` Ingo Molnar
2005-11-16  9:46                   ` Steven Rostedt
2005-11-16 10:03                     ` Ingo Molnar
2005-11-16  8:32                 ` Ingo Molnar
2005-11-16  9:40                   ` Steven Rostedt

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=1132115386.5047.61.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markknecht@gmail.com \
    --cc=mingo@elte.hu \
    --cc=pavel@suse.cz \
    --cc=tglx@linutronix.de \
    /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