mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robert Love <rml@tech9.net>
To: torvalds@transmeta.com
Cc: piggin@cyberone.com.au, linux-kernel@vger.kernel.org
Subject: [PATCH] sys_ioperm: might_sleep fix and optimization
Date: 02 Oct 2002 15:05:17 -0400	[thread overview]
Message-ID: <1033585517.24108.64.camel@phantasy> (raw)

A might_sleep() check caught sys_ioperm() calling kmalloc() whilst
atomic.

The issue is we call get_cpu() prior to kmalloc().  The fix is simply to
move the get_cpu() further south, which has the added bonus of shrinking
the non-preemptibility region by a few instructions.  Credit to Nick
Piggin.

I also added some comments.

Patch is against current BK, please apply.

	Robert Love

diff -urN linux-2.5.40/arch/i386/kernel/ioport.c linux/arch/i386/kernel/ioport.c
--- linux-2.5.40/arch/i386/kernel/ioport.c	Tue Oct  1 03:06:59 2002
+++ linux/arch/i386/kernel/ioport.c	Wed Oct  2 15:01:53 2002
@@ -49,8 +49,11 @@
 	}
 }
 
-/*
- * this changes the io permissions bitmap in the current task.
+/**
+ * sys_ioperm - sets the I/O permission bits for the current process
+ * @from: starting port address
+ * @num: number of bytes from starting address
+ * @turn_on: value to change the permission bits to
  */
 asmlinkage int sys_ioperm(unsigned long from, unsigned long num, int turn_on)
 {
@@ -63,16 +66,14 @@
 	if (turn_on && !capable(CAP_SYS_RAWIO))
 		return -EPERM;
 
-	tss = init_tss + get_cpu();
-
 	/*
 	 * If it's the first ioperm() call in this thread's lifetime, set the
 	 * IO bitmap up. ioperm() is much less timing critical than clone(),
 	 * this is why we delay this operation until now:
 	 */
 	if (!t->ts_io_bitmap) {
-		unsigned long *bitmap;
-		bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+		unsigned long *bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+
 		if (!bitmap) {
 			ret = -ENOMEM;
 			goto out;
@@ -83,11 +84,14 @@
 		 */
 		memset(bitmap, 0xff, IO_BITMAP_BYTES);
 		t->ts_io_bitmap = bitmap;
+
 		/*
 		 * this activates it in the TSS
 		 */
+		tss = init_tss + get_cpu();
 		tss->bitmap = IO_BITMAP_OFFSET;
-	}
+	} else
+		tss = init_tss + get_cpu();
 
 	/*
 	 * do it in the per-thread copy and in the TSS ...
@@ -95,8 +99,9 @@
 	set_bitmap(t->ts_io_bitmap, from, num, !turn_on);
 	set_bitmap(tss->io_bitmap, from, num, !turn_on);
 
-out:
 	put_cpu();
+
+out:
 	return ret;
 }
 




                 reply	other threads:[~2002-10-02 18:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1033585517.24108.64.camel@phantasy \
    --to=rml@tech9.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=piggin@cyberone.com.au \
    --cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®