From: Benjamin LaHaise <bcrl@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [patch] 2.5.20 x86 iobitmap cleanup
Date: Thu, 13 Jun 2002 02:20:33 -0400 [thread overview]
Message-ID: <20020613022033.H4081@redhat.com> (raw)
In-Reply-To: <20020606011546.A10030@redhat.com> <Pine.LNX.4.33.0206121300330.1533-100000@penguin.transmeta.com>
On Wed, Jun 12, 2002 at 01:04:09PM -0700, Linus Torvalds wrote:
> Why do you introduce a arch_dispose_thread_struct(), instead of just
> making the x86 exit_thread() do it?
That makes much more sense. Below is an updated patch against cset
1.479 that allocs in sys_ioperm() and copy_thread() and frees in
exit_thread(). It also gets rid of the IO_BITMAP_SIZE+1 crap, as
only the tss actually needs the tail long, and we weren't copying
it into the bitmap anyways. There is a test program at
http://www.kvack.org/~blah/iobitmap.c . Side note: double kfree()
does not trigger a BUG()...
-ben
--
"You will be reincarnated as a toad; and you will be much happier."
:r ~/patches/v2.5/v2.5.21.5-io_bitmap-B0.diff
diff -urN linus-2.5/arch/i386/kernel/ioport.c work-2.5.diff/arch/i386/kernel/ioport.c
--- linus-2.5/arch/i386/kernel/ioport.c Wed Jun 12 20:59:11 2002
+++ work-2.5.diff/arch/i386/kernel/ioport.c Thu Jun 13 02:10:59 2002
@@ -10,10 +10,10 @@
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/ioport.h>
-#include <linux/mm.h>
#include <linux/smp.h>
#include <linux/smp_lock.h>
#include <linux/stddef.h>
+#include <linux/slab.h>
/* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
static void set_bitmap(unsigned long *bitmap, short base, short extent, int new_value)
@@ -66,12 +66,16 @@
* IO bitmap up. ioperm() is much less timing critical than clone(),
* this is why we delay this operation until now:
*/
- if (!t->ioperm) {
+ if (!t->ts_io_bitmap) {
+ unsigned long *bitmap;
+ bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+ if (!bitmap)
+ return -ENOMEM;
/*
* just in case ...
*/
- memset(t->io_bitmap,0xff,(IO_BITMAP_SIZE+1)*4);
- t->ioperm = 1;
+ memset(bitmap, 0xff, IO_BITMAP_BYTES);
+ t->ts_io_bitmap = bitmap;
/*
* this activates it in the TSS
*/
@@ -81,7 +85,7 @@
/*
* do it in the per-thread copy and in the TSS ...
*/
- set_bitmap(t->io_bitmap, from, num, !turn_on);
+ set_bitmap(t->ts_io_bitmap, from, num, !turn_on);
set_bitmap(tss->io_bitmap, from, num, !turn_on);
return 0;
diff -urN linus-2.5/arch/i386/kernel/process.c work-2.5.diff/arch/i386/kernel/process.c
--- linus-2.5/arch/i386/kernel/process.c Wed Jun 12 20:59:11 2002
+++ work-2.5.diff/arch/i386/kernel/process.c Thu Jun 13 02:03:36 2002
@@ -509,7 +509,13 @@
*/
void exit_thread(void)
{
- /* nothing to do ... */
+ struct task_struct *tsk = current;
+
+ /* The process may have allocated an io port bitmap... nuke it. */
+ if (unlikely(NULL != tsk->thread.ts_io_bitmap)) {
+ kfree(tsk->thread.ts_io_bitmap);
+ tsk->thread.ts_io_bitmap = NULL;
+ }
}
void flush_thread(void)
@@ -549,6 +555,7 @@
struct task_struct * p, struct pt_regs * regs)
{
struct pt_regs * childregs;
+ struct task_struct *tsk;
childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long) p->thread_info)) - 1;
struct_cpy(childregs, regs);
@@ -563,8 +570,17 @@
savesegment(fs,p->thread.fs);
savesegment(gs,p->thread.gs);
- unlazy_fpu(current);
- struct_cpy(&p->thread.i387, ¤t->thread.i387);
+ tsk = current;
+ unlazy_fpu(tsk);
+ struct_cpy(&p->thread.i387, &tsk->thread.i387);
+
+ if (unlikely(NULL != tsk->thread.ts_io_bitmap)) {
+ p->thread.ts_io_bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+ if (!p->thread.ts_io_bitmap)
+ return -ENOMEM;
+ memcpy(p->thread.ts_io_bitmap, tsk->thread.ts_io_bitmap,
+ IO_BITMAP_BYTES);
+ }
return 0;
}
@@ -685,8 +701,8 @@
loaddebug(next, 7);
}
- if (unlikely(prev->ioperm || next->ioperm)) {
- if (next->ioperm) {
+ if (unlikely(prev->ts_io_bitmap || next->ts_io_bitmap)) {
+ if (next->ts_io_bitmap) {
/*
* 4 cachelines copy ... not good, but not that
* bad either. Anyone got something better?
@@ -695,8 +711,8 @@
* and playing VM tricks to switch the IO bitmap
* is not really acceptable.]
*/
- memcpy(tss->io_bitmap, next->io_bitmap,
- IO_BITMAP_SIZE*sizeof(unsigned long));
+ memcpy(tss->io_bitmap, next->ts_io_bitmap,
+ IO_BITMAP_BYTES);
tss->bitmap = IO_BITMAP_OFFSET;
} else
/*
diff -urN linus-2.5/include/asm-i386/processor.h work-2.5.diff/include/asm-i386/processor.h
--- linus-2.5/include/asm-i386/processor.h Wed Jun 12 20:59:17 2002
+++ work-2.5.diff/include/asm-i386/processor.h Thu Jun 13 02:02:30 2002
@@ -267,6 +267,7 @@
* Size of io_bitmap in longwords: 32 is ports 0-0x3ff.
*/
#define IO_BITMAP_SIZE 32
+#define IO_BITMAP_BYTES (IO_BITMAP_SIZE * 4)
#define IO_BITMAP_OFFSET offsetof(struct tss_struct,io_bitmap)
#define INVALID_IO_BITMAP_OFFSET 0x8000
@@ -370,8 +371,7 @@
unsigned long screen_bitmap;
unsigned long v86flags, v86mask, v86mode, saved_esp0;
/* IO permissions */
- int ioperm;
- unsigned long io_bitmap[IO_BITMAP_SIZE+1];
+ unsigned long *ts_io_bitmap;
};
#define INIT_THREAD { \
@@ -381,7 +381,7 @@
0, 0, 0, \
{ { 0, }, }, /* 387 state */ \
0,0,0,0,0,0, \
- 0,{~0,} /* io permissions */ \
+ NULL, /* io permissions */ \
}
#define INIT_TSS { \
prev parent reply other threads:[~2002-06-13 6:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-06 5:15 [patch] 2.5.20 x86 iobitmap cleanup Benjamin LaHaise
2002-06-12 20:04 ` Linus Torvalds
2002-06-13 6:20 ` Benjamin LaHaise [this message]
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=20020613022033.H4081@redhat.com \
--to=bcrl@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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