search for: config_x86_ioport

On the vast majority of modern systems, no processes will use the userspsace I/O syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Since these syscalls only exist to support rare legacy userspace programs, X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of space, this also reduces the size of several m...

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of space, this also reduces the size of several major kern...

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of space, this also reduces the size of several major kern...

On the vast majority of modern systems, no processes will use the userspsace I/O syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of space, this also reduces the size of several major kern...

...y by Intel, Brocade/Vyatta, and 6Wind. Sorry, it has to stay. On Mon, Oct 21, 2013 at 7:35 PM, Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Since these syscalls only exist to support rare legacy > userspace programs, X86_IOPORT does not depend on EXPERT, though it does > still default to y. > > In addition to saving a significant amount of space, this also reduc...

...y by Intel, Brocade/Vyatta, and 6Wind. Sorry, it has to stay. On Mon, Oct 21, 2013 at 7:35 PM, Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Since these syscalls only exist to support rare legacy > userspace programs, X86_IOPORT does not depend on EXPERT, though it does > still default to y. > > In addition to saving a significant amount of space, this also reduc...

This patch series makes it possible to compile out the iopl and ioperm system calls, which allow privileged processes to request permission to directly poke I/O ports from userspace. Nothing on a modern Linux system uses these calls anymore, and anything new should be using /dev/port instead, or better yet writing a driver. Copying the bloat-o-meter stats from the final patch: 32-bit

This patch series makes it possible to compile out the iopl and ioperm system calls, which allow privileged processes to request permission to directly poke I/O ports from userspace. Nothing on a modern Linux system uses these calls anymore, and anything new should be using /dev/port instead, or better yet writing a driver. Copying the bloat-o-meter stats from the final patch: 32-bit

Hi Josh, On Tue, Oct 22, 2013, at 3:35, Josh Triplett wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Since these syscalls only exist to support rare legacy > userspace programs, X86_IOPORT does not depend on EXPERT, though it does > still default to y. > > In addition to saving a significant amount of space, this also redu...

Hi Josh, On Tue, Oct 22, 2013, at 3:35, Josh Triplett wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Since these syscalls only exist to support rare legacy > userspace programs, X86_IOPORT does not depend on EXPERT, though it does > still default to y. > > In addition to saving a significant amount of space, this also redu...

On the vast majority of modern systems, no processes will use the userspsace I/O syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of space, this also reduces the size of several major kern...

On the vast majority of modern systems, no processes will use the userspsace I/O syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of space, this also reduces the size of several major kern...

On Wed, Oct 29, 2014 at 9:10 AM, Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, > CONFIG_X86_IOPORT, to support configuring them out of the kernel > entirely. Most current systems do not run programs using these > syscalls, so X86_IOPORT does not depend on EXPERT, though it does still > default to y. > > In addition to saving a significant amount of space, this also reduces > t...

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett

...fication in copy_thread to make subsequent changes easier. The second patch simplifies the complex calculation of the TSS segment limit, which also makes it easier to change in the last patch. Patches 3-9 introduce helpers to make it easier to compile out IO. The last patch adds and uses the new CONFIG_X86_IOPORT to support compiling out userspace IO. v3 had patches 3-10 as a single patch; v4 splits out the various helpers and macros into separate patches, as requested by Thomas Gleixner. I've verified that this compiles after each patch. Josh Triplett (10): x86: process: Unify 32-bit and 64-bit co...

...fication in copy_thread to make subsequent changes easier. The second patch simplifies the complex calculation of the TSS segment limit, which also makes it easier to change in the last patch. Patches 3-9 introduce helpers to make it easier to compile out IO. The last patch adds and uses the new CONFIG_X86_IOPORT to support compiling out userspace IO. v3 had patches 3-10 as a single patch; v4 splits out the various helpers and macros into separate patches, as requested by Thomas Gleixner. I've verified that this compiles after each patch. Josh Triplett (10): x86: process: Unify 32-bit and 64-bit co...

...86/kernel/process-io.h > > +++ b/arch/x86/kernel/process-io.h > > @@ -1,9 +1,17 @@ > > #ifndef _X86_KERNEL_PROCESS_IO_H > > #define _X86_KERNEL_PROCESS_IO_H > > > > +static inline void clear_thread_io_bitmap(struct task_struct *p) > > +{ > > +#ifdef CONFIG_X86_IOPORT > > + p->thread.io_bitmap_ptr = NULL; > > +#endif /* CONFIG_X86_IOPORT */ > > +} > > Personally, I prefer seeing these kinds of optional functions declared > in a single block rather than having the #ifdefs inside the functions: > > #ifdef CONFIG_X86_IOPO...