aboutsummaryrefslogtreecommitdiff
path: root/arch/i386/kernel/ioport.c
AgeCommit message (Collapse)Author
2005-11-05[PATCH] reset tss->io_bitmap_owner in sys_ioperm()Bart Oldeman
my patch "x86: initialise tss->io_bitmap_owner to something" (commit ID d5cd4aadd3d220afac8e3e6d922e333592551f7d) introduced a problem with a program (DOSEMU) that called ioperm after already doing some port i/o. The problem is that a process switch return causes tss->io_bitmap_base to be set to IO_BITMAP_OFFSET so that the fault (that *really* sets the io bitmap) never triggers. This fixes that regression. Signed-off-by: Bart Oldeman <bartoldeman@users.sourceforge.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05[PATCH] x86: make IOPL explicitZachary Amsden
The pushf/popf in switch_to are ONLY used to switch IOPL. Making this explicit in C code is more clear. This pushf/popf pair was added as a bugfix for leaking IOPL to unprivileged processes when using sysenter/sysexit based system calls (sysexit does not restore flags). When requesting an IOPL change in sys_iopl(), it is just as easy to change the current flags and the flags in the stack image (in case an IRET is required), but there is no reason to force an IRET if we came in from the SYSENTER path. This change is the minimal solution for supporting a paravirtualized Linux kernel that allows user processes to run with I/O privilege. Other solutions require radical rewrites of part of the low level fault / system call handling code, or do not fully support sysenter based system calls. Unfortunately, this added one field to the thread_struct. But as a bonus, on P4, the fastest time measured for switch_to() went from 312 to 260 cycles, a win of about 17% in the fast case through this performance critical path. Signed-off-by: Zachary Amsden <zach@vmware.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!