search for: heukelum

...truct tss_struct, stack) - 1) > + I wonder if the 'stack' in tss_struct has any meaning anymore. Can it be removed? If so, the offsetof can be changed to sizeof(struct tss_struct), which looks more natural to me. Even so, I think this is already an improvement. Acked-by: Alexander van Heukelum <heukelum at fastmail.fm> > struct tss_struct { > /* > * The hardware state: > -- > 1.8.4.rc3 >

...truct tss_struct, stack) - 1) > + I wonder if the 'stack' in tss_struct has any meaning anymore. Can it be removed? If so, the offsetof can be changed to sizeof(struct tss_struct), which looks more natural to me. Even so, I think this is already an improvement. Acked-by: Alexander van Heukelum <heukelum at fastmail.fm> > struct tss_struct { > /* > * The hardware state: > -- > 1.8.4.rc3 >

...omplex comment to explain. Replace that calculation with a simpler one based on the offsetof the "stack" field that follows the array. That then removes the last use of IO_BITMAP_OFFSET, so delete it. Signed-off-by: Josh Triplett <josh at joshtriplett.org> Acked-by: Alexander van Heukelum <heukelum at fastmail.fm> --- v2: Rebased. Added a comment explaining the -1 in the calculation. arch/x86/include/asm/desc.h | 11 +---------- arch/x86/include/asm/processor.h | 4 +++- 2 files changed, 4 insertions(+), 11 deletions(-) diff --git a/arch/x86/include/asm/desc.h b/arch...

Hi Josh, Since you added me to the CC, I had a look... Comments inline On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > 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

Hi Josh, Since you added me to the CC, I had a look... Comments inline On Tue, Oct 22, 2013, at 3:34, Josh Triplett wrote: > 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

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

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

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

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

...m> Alexander Sverdlin <alexander.sverdlin.ext@nsn.com> Alexander Sverdlin <alexander.sverdlin@gmx.de> Alexander Sverdlin <alexander.sverdlin@nsn.com> Alexander Sverdlin <alexander.sverdlin@sysgo.com> Alexander Sverdlin <subaparts@yandex.ru> Alexander van Heukelum <heukelum@fastmail.fm> Alexander Varnin <fenixk19@mail.ru> Alexandra Chin <alexandra.chin@tw.synaptics.com> Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru> Alexandra Vintila <andavintila@gmail.com> Alexandre Belloni <abelloni@adeneo-embedded.com&...

...m> Alexander Sverdlin <alexander.sverdlin.ext@nsn.com> Alexander Sverdlin <alexander.sverdlin@gmx.de> Alexander Sverdlin <alexander.sverdlin@nsn.com> Alexander Sverdlin <alexander.sverdlin@sysgo.com> Alexander Sverdlin <subaparts@yandex.ru> Alexander van Heukelum <heukelum@fastmail.fm> Alexander Varnin <fenixk19@mail.ru> Alexandra Chin <alexandra.chin@tw.synaptics.com> Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru> Alexandra Vintila <andavintila@gmail.com> Alexandre Belloni <abelloni@adeneo-embedded.com&...

...m> Alexander Sverdlin <alexander.sverdlin.ext@nsn.com> Alexander Sverdlin <alexander.sverdlin@gmx.de> Alexander Sverdlin <alexander.sverdlin@nsn.com> Alexander Sverdlin <alexander.sverdlin@sysgo.com> Alexander Sverdlin <subaparts@yandex.ru> Alexander van Heukelum <heukelum@fastmail.fm> Alexander Varnin <fenixk19@mail.ru> Alexander Z Lam <azl@google.com> Alexandr Ivanov <alexandr.sky@gmail.com> Alexandra Chin <alexandra.chin@tw.synaptics.com> Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru> Alexandra V...

...m> Alexander Sverdlin <alexander.sverdlin.ext@nsn.com> Alexander Sverdlin <alexander.sverdlin@gmx.de> Alexander Sverdlin <alexander.sverdlin@nsn.com> Alexander Sverdlin <alexander.sverdlin@sysgo.com> Alexander Sverdlin <subaparts@yandex.ru> Alexander van Heukelum <heukelum@fastmail.fm> Alexander Varnin <fenixk19@mail.ru> Alexander Z Lam <azl@google.com> Alexandr Ivanov <alexandr.sky@gmail.com> Alexandra Chin <alexandra.chin@tw.synaptics.com> Alexandra N. Kossovsky <Alexandra.Kossovsky@oktetlabs.ru> Alexandra V...