Re: 32-bit powerpc, aty128fb: vmap allocation for size 135168 failed

> Meelis Roos writes: > > > I was trying 4.13.0-rc5-00075-gac9a40905a61 on my PowerMac G4 with 1G > > RAM and after some time of sddm respawning and X trying to restart, > > dmesg is full of messages about vmap allocation failures. > > Did it just start happening? ie. did rc4

Re: 32-bit powerpc, aty128fb: vmap allocation for size 135168 failed

> Meelis Roos writes: > > > I was trying 4.13.0-rc5-00075-gac9a40905a61 on my PowerMac G4 with 1G > > RAM and after some time of sddm respawning and X trying to restart, > > dmesg is full of messages about vmap allocation failures. > > Did it just start happening? ie. did rc4 work? It goes

Re: [PATCH] X.509: Fix the buffer overflow in the utility function for OID string

On Sat, 19 Aug 2017 06:19:44 +0200, Lee, Chun-Yi wrote: > > From: Takashi Iwai > > The sprint_oid() utility function doesn't properly check the buffer > size that it causes that the warning in vsnprintf() be triggered. > For example on v4.1 kernel: > > [ 49.612536]

Re: [PATCH] X.509: Fix the buffer overflow in the utility function for OID string

On Sat, 19 Aug 2017 06:19:44 +0200, Lee, Chun-Yi wrote: > > From: Takashi Iwai > > The sprint_oid() utility function doesn't properly check the buffer > size that it causes that the warning in vsnprintf() be triggered. > For example on v4.1 kernel: > > [ 49.612536] [ cut here

Re: [PATCH v2] sched/fair: Make PELT signal more accurate

On Fri, 2017-08-18 at 16:50 -0700, Joel Fernandes wrote: > The PELT signal (sa->load_avg and sa->util_avg) are not updated if the amount > accumulated during a single update doesn't cross a period boundary. This is > fine in cases where the amount accrued is much smaller than the size of a >

Re: [PATCH v2] sched/fair: Make PELT signal more accurate

On Fri, 2017-08-18 at 16:50 -0700, Joel Fernandes wrote: > The PELT signal (sa->load_avg and sa->util_avg) are not updated if the amount > accumulated during a single update doesn't cross a period boundary. This is > fine in cases where the amount accrued is much smaller than the size of a >

[PATCH v2] membarrier: Document scheduler barrier requirements

Document the membarrier requirement on having a full memory barrier in __schedule() after coming from user-space, before storing to rq->curr. It is provided by smp_mb__before_spinlock() in __schedule(). Document that membarrier requires a full barrier on transition from kernel thread to userspace

[PATCH v2] membarrier: Document scheduler barrier requirements

Document the membarrier requirement on having a full memory barrier in __schedule() after coming from user-space, before storing to rq->curr. It is provided by smp_mb__before_spinlock() in __schedule(). Document that membarrier requires a full barrier on transition from kernel thread to userspace

[PATCH] X.509: Fix the buffer overflow in the utility function for OID string

From: Takashi Iwai The sprint_oid() utility function doesn't properly check the buffer size that it causes that the warning in vsnprintf() be triggered. For example on v4.1 kernel: [ 49.612536] [ cut here ] [ 49.612543] WARNING: CPU: 0 PID: 2357 at

[PATCH] X.509: Fix the buffer overflow in the utility function for OID string

From: Takashi Iwai The sprint_oid() utility function doesn't properly check the buffer size that it causes that the warning in vsnprintf() be triggered. For example on v4.1 kernel: [ 49.612536] [ cut here ] [ 49.612543] WARNING: CPU: 0 PID: 2357 at

Re: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset

On Fri, 18 Aug 2017 08:57:09 -0700 David Daney wrote: > On 08/18/2017 07:12 AM, Alex Williamson wrote: > > On Fri, 18 Aug 2017 15:42:31 +0200 > > Jan Glauber wrote: > > > >> On Thu, Aug 17, 2017 at 07:00:17AM -0600, Alex Williamson

Re: [PATCH v2 3/3] vfio/pci: Don't probe devices that can't be reset

On Fri, 18 Aug 2017 08:57:09 -0700 David Daney wrote: > On 08/18/2017 07:12 AM, Alex Williamson wrote: > > On Fri, 18 Aug 2017 15:42:31 +0200 > > Jan Glauber wrote: > > > >> On Thu, Aug 17, 2017 at 07:00:17AM -0600, Alex Williamson wrote: > >>> On Thu, 17 Aug 2017 10:14:23 +0200 > >>> Jan

[PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device

From: "Thang Q. Nguyen" For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration"), sysdev points to devices known to the system firmware or hardware for DMA parameters. However, the parent of the system firmware/hardware device checking logic does not work in

[PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device

From: "Thang Q. Nguyen" For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration"), sysdev points to devices known to the system firmware or hardware for DMA parameters. However, the parent of the system firmware/hardware device checking logic does not work in ACPI boot mode.

Re: [PATCH] staging: lustre: uapi: properly include lustre_errno.h

On Fri, Aug 18, 2017 at 11:04:14PM -0400, James Simmons wrote: > The path for lustre_errno.h was not updated to the new path > for errno.c. Also the header lustre_net.h uses code found in > lustre_errno.h but doesn't include the header directly. It > is easy to forget to add the header

Re: [PATCH] staging: lustre: uapi: properly include lustre_errno.h

On Fri, Aug 18, 2017 at 11:04:14PM -0400, James Simmons wrote: > The path for lustre_errno.h was not updated to the new path > for errno.c. Also the header lustre_net.h uses code found in > lustre_errno.h but doesn't include the header directly. It > is easy to forget to add the header

Re: [f2fs-dev] [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

On 2017/8/18 23:09, Yunlong Song wrote: > This patch adds cur_reserved_blocks to extend reserved_blocks sysfs > interface to be soft threshold, which allows user configure it exceeding > current available user space. To ensure there is enough space for > supporting system's activation, this patch

Re: [f2fs-dev] [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

On 2017/8/18 23:09, Yunlong Song wrote: > This patch adds cur_reserved_blocks to extend reserved_blocks sysfs > interface to be soft threshold, which allows user configure it exceeding > current available user space. To ensure there is enough space for > supporting system's activation, this patch

[PATCH] staging: lustre: uapi: properly include lustre_errno.h

The path for lustre_errno.h was not updated to the new path for errno.c. Also the header lustre_net.h uses code found in lustre_errno.h but doesn't include the header directly. It is easy to forget to add the header lustre_errno.h before including lustre_net.h so it is just easier to include

[PATCH] staging: lustre: uapi: properly include lustre_errno.h

The path for lustre_errno.h was not updated to the new path for errno.c. Also the header lustre_net.h uses code found in lustre_errno.h but doesn't include the header directly. It is easy to forget to add the header lustre_errno.h before including lustre_net.h so it is just easier to include

Re: [RFC PATCH v3] pci: Concurrency issue during pci enable bridge

On Wed, Aug 16, 2017 at 10:33:12PM +0530, Srinath Mannam wrote: > Hi Bjorn, > > Thank you for the feedback. > > My comments are in lined. > > On Wed, Aug 16, 2017 at 7:13 PM, Bjorn Helgaas wrote: > > On Fri, Aug 04, 2017 at 08:27:28PM +0530, Srinath Mannam wrote: > >>

Re: [RFC PATCH v3] pci: Concurrency issue during pci enable bridge

On Wed, Aug 16, 2017 at 10:33:12PM +0530, Srinath Mannam wrote: > Hi Bjorn, > > Thank you for the feedback. > > My comments are in lined. > > On Wed, Aug 16, 2017 at 7:13 PM, Bjorn Helgaas wrote: > > On Fri, Aug 04, 2017 at 08:27:28PM +0530, Srinath Mannam wrote: > >> Concurrency issue is

Re: [PATCH] dts: Make it easier to enable __symbols__ generation in dtb files

On Wed, Aug 16, 2017 at 11:32:08PM -0700, Frank Rowand wrote: > Hi Tom, > > Some nit picking on the patch comment. :-) > > > On 08/16/17 17:35, Tom Rini wrote: > > This introduces the variabe DTC_EXTRA_FLAGS to allow for additional > > flags to be passed to dtc. While this can have many uses

Re: [PATCH] dts: Make it easier to enable __symbols__ generation in dtb files

On Wed, Aug 16, 2017 at 11:32:08PM -0700, Frank Rowand wrote: > Hi Tom, > > Some nit picking on the patch comment. :-) > > > On 08/16/17 17:35, Tom Rini wrote: > > This introduces the variabe DTC_EXTRA_FLAGS to allow for additional > > flags to be passed to dtc. While this can have many uses

[PATCH] iio: accel: mma8452: code improvements to handle more than one event

This driver supports multiple devices like mma8653, mma8652, mma8452, mma8453 and fxls8471. Almost all these devices have more than one event. Current driver design hardcodes the event specific information, so only one event can be supported by this driver and current design doesn't have the

[PATCH] iio: accel: mma8452: code improvements to handle more than one event

This driver supports multiple devices like mma8653, mma8652, mma8452, mma8453 and fxls8471. Almost all these devices have more than one event. Current driver design hardcodes the event specific information, so only one event can be supported by this driver and current design doesn't have the

[PATCH] serial: earlycon: Only try fdt when specify 'earlycon' exactly

When moving earlycon early_param handling to serial, the devicetree earlycons enable condition changed slightly. We used to only do that for 'console'/'earlycon', but now would also for 'console='/'earlycon='. Fix it by using the same condition like before. Fixes: d503187b6cc4 (of/serial: move

[PATCH] serial: earlycon: Only try fdt when specify 'earlycon' exactly

When moving earlycon early_param handling to serial, the devicetree earlycons enable condition changed slightly. We used to only do that for 'console'/'earlycon', but now would also for 'console='/'earlycon='. Fix it by using the same condition like before. Fixes: d503187b6cc4 (of/serial: move

Re: [PATCH v9 2/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 08/18/17 at 04:10pm, Ard Biesheuvel wrote: > On 17 August 2017 at 14:04, Baoquan He wrote: > > Thanks a lot for helping improving the patch log, Ingo! Will pay more > > attention to the description in words and paragraph partition of log. > > > >> > >> So if EFI is detected,

Re: [patch v3 2/3] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

-core-driver/20170818-114739 config: um-allyesconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=um All errors (new ones prefixed by >>): arch/um/drivers/vde.o: In fu

Re: [PATCH v9 2/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

On 08/18/17 at 04:10pm, Ard Biesheuvel wrote: > On 17 August 2017 at 14:04, Baoquan He wrote: > > Thanks a lot for helping improving the patch log, Ingo! Will pay more > > attention to the description in words and paragraph partition of log. > > > >> > >> So if EFI is detected, iterate EFI

Re: [patch v3 2/3] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

-core-driver/20170818-114739 config: um-allyesconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=um All errors (new ones prefixed by >>): arch/um/drivers/vde.o: In fu

Re: [PATCH 0/3] MIPS,bpf: Improvements for MIPS eBPF JIT

On 08/19/2017 01:40 AM, David Daney wrote: Here are several improvements and bug fixes for the MIPS eBPF JIT. The main change is the addition of support for JLT, JLE, JSLT and JSLE ops, that were recently added. Also fix WARN output when used with preemptable kernel, and a small

Re: [PATCH 0/3] MIPS,bpf: Improvements for MIPS eBPF JIT

On 08/19/2017 01:40 AM, David Daney wrote: Here are several improvements and bug fixes for the MIPS eBPF JIT. The main change is the addition of support for JLT, JLE, JSLT and JSLE ops, that were recently added. Also fix WARN output when used with preemptable kernel, and a small

Re: [PATCH 1/2] iommu/amd: Fix compiler warning in copy_device_table()

On 08/19/17 at 12:40am, Joerg Roedel wrote: > From: Joerg Roedel > > This was reported by the kbuild bot. The condition in which > entry would be used uninitialized can not happen, because > when there is no iommu this function would never be called. > But its no fast-path, so

Re: [PATCH 1/2] iommu/amd: Fix compiler warning in copy_device_table()

On 08/19/17 at 12:40am, Joerg Roedel wrote: > From: Joerg Roedel > > This was reported by the kbuild bot. The condition in which > entry would be used uninitialized can not happen, because > when there is no iommu this function would never be called. > But its no fast-path, so fix the warning

Re: [GIT PULL] apparmor updates for next

On Fri, 18 Aug 2017, John Johansen wrote: > Hi James, > > Please pull these apparmor changes for next. > Pulled, thanks. -- James Morris

Re: [GIT PULL] apparmor updates for next

On Fri, 18 Aug 2017, John Johansen wrote: > Hi James, > > Please pull these apparmor changes for next. > Pulled, thanks. -- James Morris

Re: [PATCH] selftests: timers: Fix run_destructive_tests target to handle skipped tests

On Thu, Aug 17, 2017 at 3:48 PM, Shuah Khan wrote: > When a test exits with skip exit code of 4, "make run_destructive_tests" > halts testing. Fix run_destructive_tests target to handle error exit codes. > > Reported-by: John Stultz >

Re: [PATCH] selftests: timers: Fix run_destructive_tests target to handle skipped tests

On Thu, Aug 17, 2017 at 3:48 PM, Shuah Khan wrote: > When a test exits with skip exit code of 4, "make run_destructive_tests" > halts testing. Fix run_destructive_tests target to handle error exit codes. > > Reported-by: John Stultz > Signed-off-by: Shuah Khan > --- >

[PATCH v8 01/28] x86/mm: Relocate page fault error codes to traps.h

Up to this point, only fault.c used the definitions of the page fault error codes. Thus, it made sense to keep them within such file. Other portions of code might be interested in those definitions too. For instance, the User- Mode Instruction Prevention emulation code will use such definitions to

[PATCH v8 01/28] x86/mm: Relocate page fault error codes to traps.h

Up to this point, only fault.c used the definitions of the page fault error codes. Thus, it made sense to keep them within such file. Other portions of code might be interested in those definitions too. For instance, the User- Mode Instruction Prevention emulation code will use such definitions to

[PATCH v8 06/28] x86/mpx: Do not use SIB.index if its value is 100b and ModRM.mod is not 11b

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when ModRM.mod !=11b and ModRM.rm = 100b indexed register-indirect addressing is used. In other words, a SIB byte follows the ModRM byte. In the specific case of SIB.index = 100b, the

[PATCH v8 06/28] x86/mpx: Do not use SIB.index if its value is 100b and ModRM.mod is not 11b

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when ModRM.mod !=11b and ModRM.rm = 100b indexed register-indirect addressing is used. In other words, a SIB byte follows the ModRM byte. In the specific case of SIB.index = 100b, the

[PATCH v8 07/28] x86/mpx: Do not use SIB.base if its value is 101b and ModRM.mod = 0

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that if a SIB byte is used and SIB.base is 101b and ModRM.mod is zero, then the base part of the base part of the effective address computation is null. To signal this situation, a -EDOM error is

[PATCH v8 07/28] x86/mpx: Do not use SIB.base if its value is 101b and ModRM.mod = 0

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that if a SIB byte is used and SIB.base is 101b and ModRM.mod is zero, then the base part of the base part of the effective address computation is null. To signal this situation, a -EDOM error is

[PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0

Both head_32.S and head_64.S utilize the same value to initialize the control register CR0. Also, other parts of the kernel might want to access to this initial definition (e.g., emulation code for User-Mode Instruction Prevention uses this state to provide a sane dummy value for CR0 when

[PATCH v8 02/28] x86/boot: Relocate definition of the initial state of CR0

Both head_32.S and head_64.S utilize the same value to initialize the control register CR0. Also, other parts of the kernel might want to access to this initial definition (e.g., emulation code for User-Mode Instruction Prevention uses this state to provide a sane dummy value for CR0 when

[PATCH v8 03/28] ptrace,x86: Make user_64bit_mode() available to 32-bit builds

In its current form, user_64bit_mode() can only be used when CONFIG_X86_64 is selected. This implies that code built with CONFIG_X86_64=n cannot use it. If a piece of code needs to be built for both CONFIG_X86_64=y and CONFIG_X86_64=n and wants to use this function, it needs to wrap it in an

[PATCH v8 00/28] x86: Enable User-Mode Instruction Prevention

This is v8 of this series. The seven previous submissions can be found here [1], here [2], here[3], here[4], here[5], here[6] and here[7]. This version addresses the feedback comments from Borislav Petkov received on v7. Please see details in the change log. === What is UMIP? User-Mode

[PATCH v8 03/28] ptrace,x86: Make user_64bit_mode() available to 32-bit builds

In its current form, user_64bit_mode() can only be used when CONFIG_X86_64 is selected. This implies that code built with CONFIG_X86_64=n cannot use it. If a piece of code needs to be built for both CONFIG_X86_64=y and CONFIG_X86_64=n and wants to use this function, it needs to wrap it in an

[PATCH v8 00/28] x86: Enable User-Mode Instruction Prevention

This is v8 of this series. The seven previous submissions can be found here [1], here [2], here[3], here[4], here[5], here[6] and here[7]. This version addresses the feedback comments from Borislav Petkov received on v7. Please see details in the change log. === What is UMIP? User-Mode

[PATCH v8 12/28] x86/insn-eval: Add utility functions to get segment selector

When computing a linear address and segmentation is used, we need to know the base address of the segment involved in the computation. In most of the cases, the segment base address will be zero as in USER_DS/USER32_DS. However, it may be possible that a user space program defines its own segments

[PATCH v8 12/28] x86/insn-eval: Add utility functions to get segment selector

When computing a linear address and segmentation is used, we need to know the base address of the segment involved in the computation. In most of the cases, the segment base address will be zero as in USER_DS/USER32_DS. However, it may be possible that a user space program defines its own segments

[PATCH v8 13/28] x86/insn-eval: Add utility function to get segment descriptor

The segment descriptor contains information that is relevant to how linear addresses need to be computed. It contains the default size of addresses as well as the base address of the segment. Thus, given a segment selector, we ought look at segment descriptor to correctly calculate the linear

[PATCH v8 15/28] x86/insn-eval: Add function to get default params of code segment

Obtain the default values of the address and operand sizes as specified in the D and L bits of the the segment descriptor selected by the register CS. The function can be used for both protected and long modes. For virtual-8086 mode, the default address and operand sizes are always 2 bytes. The

[PATCH v8 13/28] x86/insn-eval: Add utility function to get segment descriptor

The segment descriptor contains information that is relevant to how linear addresses need to be computed. It contains the default size of addresses as well as the base address of the segment. Thus, given a segment selector, we ought look at segment descriptor to correctly calculate the linear

[PATCH v8 15/28] x86/insn-eval: Add function to get default params of code segment

Obtain the default values of the address and operand sizes as specified in the D and L bits of the the segment descriptor selected by the register CS. The function can be used for both protected and long modes. For virtual-8086 mode, the default address and operand sizes are always 2 bytes. The

[PATCH v8 16/28] x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 101b

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when ModRM.mod is zero and ModRM.rm is 101b, a 32-bit displacement follows the ModRM byte. This means that none of the registers are used in the computation of the effective address. A return

[PATCH v8 14/28] x86/insn-eval: Add utility functions to get segment descriptor base address and limit

With segmentation, the base address of the segment is needed to compute a linear address. This base address is obtained from the applicable segment descriptor. Such segment descriptor is referenced from a segment selector. The segment selector is stored in the segment register associated with

[PATCH v8 16/28] x86/insn-eval: Indicate a 32-bit displacement if ModRM.mod is 0 and ModRM.rm is 101b

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when ModRM.mod is zero and ModRM.rm is 101b, a 32-bit displacement follows the ModRM byte. This means that none of the registers are used in the computation of the effective address. A return

[PATCH v8 14/28] x86/insn-eval: Add utility functions to get segment descriptor base address and limit

With segmentation, the base address of the segment is needed to compute a linear address. This base address is obtained from the applicable segment descriptor. Such segment descriptor is referenced from a segment selector. The segment selector is stored in the segment register associated with

[PATCH v8 04/28] uprobes/x86: Use existing definitions for segment override prefixes

Rather than using hard-coded values of the segment override prefixes, leverage the existing definitions provided in inat.h. Suggested-by: Borislav Petkov Cc: Andy Lutomirski Cc: Andrew Morton Cc: Borislav Petkov Cc:

[PATCH v8 19/28] x86/insn-eval: Add wrapper function for 32 and 64-bit addresses

The function insn_get_addr_ref() is capable of handling only 64-bit addresses. A previous commit introduced a function to handle 32-bit addresses. Invoke these two functions from a third wrapper function that calls the appropriate routine based on the address size specified in the instruction

[PATCH v8 19/28] x86/insn-eval: Add wrapper function for 32 and 64-bit addresses

The function insn_get_addr_ref() is capable of handling only 64-bit addresses. A previous commit introduced a function to handle 32-bit addresses. Invoke these two functions from a third wrapper function that calls the appropriate routine based on the address size specified in the instruction

[PATCH v8 04/28] uprobes/x86: Use existing definitions for segment override prefixes

Rather than using hard-coded values of the segment override prefixes, leverage the existing definitions provided in inat.h. Suggested-by: Borislav Petkov Cc: Andy Lutomirski Cc: Andrew Morton Cc: Borislav Petkov Cc: Masami Hiramatsu Cc: Denys Vlasenko Cc: Srikar Dronamraju Cc: Ravi V.

[PATCH v8 21/28] x86/insn-eval: Add support to resolve 16-bit addressing encodings

Tasks running in virtual-8086 mode, in protected mode with code segment descriptors that specify 16-bit default address sizes via the D bit, or via an address override prefix will use 16-bit addressing form encodings as described in the Intel 64 and IA-32 Architecture Software Developer's Manual

[PATCH v8 21/28] x86/insn-eval: Add support to resolve 16-bit addressing encodings

Tasks running in virtual-8086 mode, in protected mode with code segment descriptors that specify 16-bit default address sizes via the D bit, or via an address override prefix will use 16-bit addressing form encodings as described in the Intel 64 and IA-32 Architecture Software Developer's Manual

[PATCH v8 20/28] x86/insn-eval: Handle 32-bit address encodings in virtual-8086 mode

It is possible to utilize 32-bit address encodings in virtual-8086 mode via an address override instruction prefix. However, the range of the effective address is still limited to [0x-0x]. In such a case, return error. Also, linear addresses in virtual-8086 mode are limited to 20 bits.

[PATCH v8 20/28] x86/insn-eval: Handle 32-bit address encodings in virtual-8086 mode

It is possible to utilize 32-bit address encodings in virtual-8086 mode via an address override instruction prefix. However, the range of the effective address is still limited to [0x-0x]. In such a case, return error. Also, linear addresses in virtual-8086 mode are limited to 20 bits.

[PATCH v8 24/28] x86/umip: Force a page fault when unable to copy emulated result to user

fixup_umip_exception() will be called from do_general_protection(). If the former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV. However, when emulation is successful but the emulated result cannot be copied to user space memory, it is more accurate to issue a SIGSEGV with

[PATCH v8 05/28] x86/mpx: Use signed variables to compute effective addresses

Even though memory addresses are unsigned, the operands used to compute the effective address do have a sign. This is true for ModRM.rm, SIB.base, SIB.index as well as the displacement bytes. Thus, signed variables shall be used when computing the effective address from these operands. Once the

[PATCH v8 24/28] x86/umip: Force a page fault when unable to copy emulated result to user

fixup_umip_exception() will be called from do_general_protection(). If the former returns false, the latter will issue a SIGSEGV with SEND_SIG_PRIV. However, when emulation is successful but the emulated result cannot be copied to user space memory, it is more accurate to issue a SIGSEGV with

[PATCH v8 05/28] x86/mpx: Use signed variables to compute effective addresses

Even though memory addresses are unsigned, the operands used to compute the effective address do have a sign. This is true for ModRM.rm, SIB.base, SIB.index as well as the displacement bytes. Thus, signed variables shall be used when computing the effective address from these operands. Once the

[PATCH v8 22/28] x86/cpufeature: Add User-Mode Instruction Prevention definitions

User-Mode Instruction Prevention is a security feature present in new Intel processors that, when set, prevents the execution of a subset of instructions if such instructions are executed in user mode (CPL > 0). Attempting to execute such instructions causes a general protection exception. The

[PATCH v8 22/28] x86/cpufeature: Add User-Mode Instruction Prevention definitions

User-Mode Instruction Prevention is a security feature present in new Intel processors that, when set, prevents the execution of a subset of instructions if such instructions are executed in user mode (CPL > 0). Attempting to execute such instructions causes a general protection exception. The

[PATCH v8 23/28] x86: Add emulation code for UMIP instructions

The feature User-Mode Instruction Prevention present in recent Intel processor prevents a group of instructions (sgdt, sidt, sldt, smsw, and str) from being executed with CPL > 0. Otherwise, a general protection fault is issued. Rather than relaying to the user space the general protection fault

[PATCH v8 23/28] x86: Add emulation code for UMIP instructions

The feature User-Mode Instruction Prevention present in recent Intel processor prevents a group of instructions (sgdt, sidt, sldt, smsw, and str) from being executed with CPL > 0. Otherwise, a general protection fault is issued. Rather than relaying to the user space the general protection fault

[PATCH v8 09/28] x86/insn-eval: Do not BUG on invalid register type

We are not in a critical failure path. The invalid register type is caused when trying to decode invalid instruction bytes from a user-space program. Thus, simply print an error message. To prevent this warning from being abused from user space programs, use the rate-limited variant of pr_err().

[PATCH v8 09/28] x86/insn-eval: Do not BUG on invalid register type

We are not in a critical failure path. The invalid register type is caused when trying to decode invalid instruction bytes from a user-space program. Thus, simply print an error message. To prevent this warning from being abused from user space programs, use the rate-limited variant of pr_err().

[PATCH v8 25/28] x86: Enable User-Mode Instruction Prevention

User-Mode Instruction Prevention (UMIP) is enabled by setting/clearing a bit in %cr4. It makes sense to enable UMIP at some point while booting, before user spaces come up. Like SMAP and SMEP, is not critical to have it enabled very early during boot. This is because UMIP is relevant only when

[PATCH v8 25/28] x86: Enable User-Mode Instruction Prevention

User-Mode Instruction Prevention (UMIP) is enabled by setting/clearing a bit in %cr4. It makes sense to enable UMIP at some point while booting, before user spaces come up. Like SMAP and SMEP, is not critical to have it enabled very early during boot. This is because UMIP is relevant only when

[PATCH v8 26/28] x86/traps: Fixup general protection faults caused by UMIP

If the User-Mode Instruction Prevention CPU feature is available and enabled, a general protection fault will be issued if the instructions sgdt, sldt, sidt, str or smsw are executed from user-mode context (CPL > 0). If the fault was caused by any of the instructions protected by UMIP,

[PATCH v8 26/28] x86/traps: Fixup general protection faults caused by UMIP

If the User-Mode Instruction Prevention CPU feature is available and enabled, a general protection fault will be issued if the instructions sgdt, sldt, sidt, str or smsw are executed from user-mode context (CPL > 0). If the fault was caused by any of the instructions protected by UMIP,

[PATCH v8 27/28] selftests/x86: Add tests for User-Mode Instruction Prevention

Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a

[PATCH v8 28/28] selftests/x86: Add tests for instruction str and sldt

The instructions str and sldt are not recognized when running on virtual- 8086 mode and generate an invalid operand exception. These two instructions are protected by the Intel User-Mode Instruction Prevention (UMIP) security feature. In protected mode, if UMIP is enabled, these instructions

[PATCH v8 27/28] selftests/x86: Add tests for User-Mode Instruction Prevention

Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a

[PATCH v8 28/28] selftests/x86: Add tests for instruction str and sldt

The instructions str and sldt are not recognized when running on virtual- 8086 mode and generate an invalid operand exception. These two instructions are protected by the Intel User-Mode Instruction Prevention (UMIP) security feature. In protected mode, if UMIP is enabled, these instructions

[PATCH v8 11/28] x86/insn-eval: Add utility function to identify string instructions

String instructions are special because, in protected mode, the linear address is always obtained via the ES segment register in operands that use the (E)DI register; the DS segment register in operands that use the (E)SI register. Furthermore, segment override prefixes are ignored when

[PATCH v8 11/28] x86/insn-eval: Add utility function to identify string instructions

String instructions are special because, in protected mode, the linear address is always obtained via the ES segment register in operands that use the (E)DI register; the DS segment register in operands that use the (E)SI register. Furthermore, segment override prefixes are ignored when

[PATCH v8 08/28] x86/mpx, x86/insn: Relocate insn util functions to a new insn-eval file

Other kernel submodules can benefit from using the utility functions defined in mpx.c to obtain the addresses and values of operands contained in the general purpose registers. An instance of this is the emulation code used for instructions protected by the Intel User-Mode Instruction Prevention

[PATCH v8 08/28] x86/mpx, x86/insn: Relocate insn util functions to a new insn-eval file

Other kernel submodules can benefit from using the utility functions defined in mpx.c to obtain the addresses and values of operands contained in the general purpose registers. An instance of this is the emulation code used for instructions protected by the Intel User-Mode Instruction Prevention

[PATCH v8 18/28] x86/insn-eval: Add support to resolve 32-bit address encodings

32-bit and 64-bit address encodings are identical. Thus, the same logic could be used to resolve the effective address. However, there are two key differences: address size and enforcement of segment limits. If running a 32-bit process on a 64-bit kernel, it is best to perform the address

[PATCH v8 18/28] x86/insn-eval: Add support to resolve 32-bit address encodings

32-bit and 64-bit address encodings are identical. Thus, the same logic could be used to resolve the effective address. However, there are two key differences: address size and enforcement of segment limits. If running a 32-bit process on a 64-bit kernel, it is best to perform the address

[PATCH v8 17/28] x86/insn-eval: Incorporate segment base in linear address computation

insn_get_addr_ref() returns the effective address as defined by the section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software Developer's Manual. In order to compute the linear address, we must add to the effective address the segment base address as set in the segment descriptor. The

[PATCH v8 17/28] x86/insn-eval: Incorporate segment base in linear address computation

insn_get_addr_ref() returns the effective address as defined by the section 3.7.5.1 Vol 1 of the Intel 64 and IA-32 Architectures Software Developer's Manual. In order to compute the linear address, we must add to the effective address the segment base address as set in the segment descriptor. The

[PATCH v8 10/28] x86/insn-eval: Add a utility function to get register offsets

The function get_reg_offset() returns the offset to the register the argument specifies as indicated in an enumeration of type offset. Callers of this function would need the definition of such enumeration. This is not needed. Instead, add helper functions for this purpose. These functions are

[PATCH v8 10/28] x86/insn-eval: Add a utility function to get register offsets

The function get_reg_offset() returns the offset to the register the argument specifies as indicated in an enumeration of type offset. Callers of this function would need the definition of such enumeration. This is not needed. Instead, add helper functions for this purpose. These functions are

Re: [PATCH] iio: accel: mma8452: Bugfix to enbale and allow different events to work parallely.

This patch fixes by detaching the event related information from chip_info struct, and based on channel type and event direction the corresponding event configuration registers are picked dynamically. Hence multiple events can be handled in read/write callbacks. which chip can have which

Re: [PATCH] iio: accel: mma8452: Bugfix to enbale and allow different events to work parallely.

This patch fixes by detaching the event related information from chip_info struct, and based on channel type and event direction the corresponding event configuration registers are picked dynamically. Hence multiple events can be handled in read/write callbacks. which chip can have which

  1   2   3   4   5   6   7   8   9   10   >