search for: tss_limit

...a "long" at the end > - * of the iobitmap. See tss_struct definition in processor.h > - * > - * -1? seg base+limit should be pointing to the address of the > - * last valid byte I think it might be better to keep at least a minimal comment near the TSS_LIMIT declaration, just to explain the "-1" part, which is not entirely obvious from just reading the code. -Kees > - */ > - set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, > - IO_BITMAP_OFFSET + IO_BITMAP_BYTES + > -...

...a "long" at the end > - * of the iobitmap. See tss_struct definition in processor.h > - * > - * -1? seg base+limit should be pointing to the address of the > - * last valid byte I think it might be better to keep at least a minimal comment near the TSS_LIMIT declaration, just to explain the "-1" part, which is not entirely obvious from just reading the code. -Kees > - */ > - set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, > - IO_BITMAP_OFFSET + IO_BITMAP_BYTES + > -...

...nting to the address of the > - * last valid byte > - */ > - set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, > - IO_BITMAP_OFFSET + IO_BITMAP_BYTES + > - sizeof(unsigned long) - 1); > + set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, TSS_LIMIT); > write_gdt_entry(d, entry, &tss, DESC_TSS); > } > > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > index 987c75e..03d3003 100644 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -259,9 +259...

...nting to the address of the > - * last valid byte > - */ > - set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, > - IO_BITMAP_OFFSET + IO_BITMAP_BYTES + > - sizeof(unsigned long) - 1); > + set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, TSS_LIMIT); > write_gdt_entry(d, entry, &tss, DESC_TSS); > } > > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > index 987c75e..03d3003 100644 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -259,9 +259...

...? seg base+limit should be pointing to the address of the - * last valid byte - */ - set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, - IO_BITMAP_OFFSET + IO_BITMAP_BYTES + - sizeof(unsigned long) - 1); + set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, TSS_LIMIT); write_gdt_entry(d, entry, &tss, DESC_TSS); } diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 987c75e..03d3003 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -259,9 +259,10 @@ struct x86_hw_tss { #define IO_B...

...? seg base+limit should be pointing to the address of the - * last valid byte - */ - set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, - IO_BITMAP_OFFSET + IO_BITMAP_BYTES + - sizeof(unsigned long) - 1); + set_tssldt_descriptor(&tss, (unsigned long)addr, DESC_TSS, TSS_LIMIT); write_gdt_entry(d, entry, &tss, DESC_TSS); } diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index fdedd38..7da8794 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -259,9 +259,11 @@ struct x86_hw_tss { #define IO_B...

...gt;> - * of the iobitmap. See tss_struct definition in processor.h >> - * >> - * -1? seg base+limit should be pointing to the address of the >> - * last valid byte > > I think it might be better to keep at least a minimal comment near the > TSS_LIMIT declaration, just to explain the "-1" part, which is not > entirely obvious from just reading the code. > Agreed, although it doesn't need to be an unsigned long at all... the CPU will only ever access one extra byte past the end. -hpa

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

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

This patch series makes it possible to compile out the userspace IO system calls, iopl and ioperm. The first patch does some 32/64 unification 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.

This patch series makes it possible to compile out the userspace IO system calls, iopl and ioperm. The first patch does some 32/64 unification 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 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