[GIT PULL] parisc architecture fixes for 4.11

Hi Linus, Please pull the changes for the parisc architecture for v4.11 from git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.11-1 Nothing really important in this patchset: Fix resource leaks in error paths, coding style cleanups and code removal. Thanks, Helge

[GIT PULL] parisc architecture fixes for 4.11

Hi Linus, Please pull the changes for the parisc architecture for v4.11 from git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.11-1 Nothing really important in this patchset: Fix resource leaks in error paths, coding style cleanups and code removal. Thanks, Helge

[PATCH ALT5] audit: ignore module syscalls on inode child

Tracefs or debugfs were causing hundreds to thousands of null PATH records to be associated with the init_module and finit_module SYSCALL records on a few modules when the following rule was in place for startup: -a always,exit -F arch=x86_64 -S init_module -F key=mod-load In

[PATCH ALT5] audit: ignore module syscalls on inode child

Tracefs or debugfs were causing hundreds to thousands of null PATH records to be associated with the init_module and finit_module SYSCALL records on a few modules when the following rule was in place for startup: -a always,exit -F arch=x86_64 -S init_module -F key=mod-load In

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

Am 03.03.2017 um 15:11 schrieb Boris Brezillon: >> And add a list of successfully added notifiers, along with their >> data pointer, to the MTD device. That's simple and would also remove >> the need for notifier to have a private list of their instances as I >> had to do here. > > And then

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

Am 03.03.2017 um 15:11 schrieb Boris Brezillon: >> And add a list of successfully added notifiers, along with their >> data pointer, to the MTD device. That's simple and would also remove >> the need for notifier to have a private list of their instances as I >> had to do here. > > And then

Re: [PATCHv2] omap3isp: add support for CSI1 bus

Hi Pavel, On Thu, Mar 02, 2017 at 01:38:48PM +0100, Pavel Machek wrote: > Hi! > > > > Ok, how about this one? > > > omap3isp: add rest of CSI1 support > > > > > > CSI1 needs one more bit to be set up. Do just that. > > > > > > It is not as straightforward as I'd like, see the comments

Re: [PATCHv2] omap3isp: add support for CSI1 bus

Hi Pavel, On Thu, Mar 02, 2017 at 01:38:48PM +0100, Pavel Machek wrote: > Hi! > > > > Ok, how about this one? > > > omap3isp: add rest of CSI1 support > > > > > > CSI1 needs one more bit to be set up. Do just that. > > > > > > It is not as straightforward as I'd like, see the comments

Re: [media] omap3isp: Correctly set IO_OUT_SEL and VP_CLK_POL for CCP2 mode

Hi! > [auto build test ERROR on linuxtv-media/master] > [also build test ERROR on v4.10 next-20170303] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > Yes, the patch is against Sakari's ccp2 branch. It should work ok

Re: [media] omap3isp: Correctly set IO_OUT_SEL and VP_CLK_POL for CCP2 mode

Hi! > [auto build test ERROR on linuxtv-media/master] > [also build test ERROR on v4.10 next-20170303] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > Yes, the patch is against Sakari's ccp2 branch. It should work ok

[GIT PULL] libnvdimm fixes for 4.11-rc1

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive a fix and regression test case for nvdimm namespace label compatibility. Details: An "nvdimm namespace label" is metadata on an nvdimm that provisions dimm capacity into a

[GIT PULL] libnvdimm fixes for 4.11-rc1

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive a fix and regression test case for nvdimm namespace label compatibility. Details: An "nvdimm namespace label" is metadata on an nvdimm that provisions dimm capacity into a

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

>>> Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM >>> cortex-a15) wherein pages allocated by vmalloc are in highmem region >>> that are not addressable using 32 bit addresses and is backed by LPAE. >>> So, a 32 bit DMA cannot access these buffers at all. >>> When

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

>>> Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM >>> cortex-a15) wherein pages allocated by vmalloc are in highmem region >>> that are not addressable using 32 bit addresses and is backed by LPAE. >>> So, a 32 bit DMA cannot access these buffers at all. >>> When

Re: [PATCH] ARM: dts: exynos: Use thermal fuse value for thermal zone 0 on Exynos5420

Hello Krzysztof, On 02/11/2017 05:14 PM, Krzysztof Kozlowski wrote: > In Odroid XU3 Lite board, the temperature levels reported for thermal > zone 0 were weird. In warm room: > /sys/class/thermal/thermal_zone0/temp:32000 > /sys/class/thermal/thermal_zone1/temp:51000 >

Re: [PATCH] ARM: dts: exynos: Use thermal fuse value for thermal zone 0 on Exynos5420

Hello Krzysztof, On 02/11/2017 05:14 PM, Krzysztof Kozlowski wrote: > In Odroid XU3 Lite board, the temperature levels reported for thermal > zone 0 were weird. In warm room: > /sys/class/thermal/thermal_zone0/temp:32000 > /sys/class/thermal/thermal_zone1/temp:51000 >

[PULL 0/3] Xtensa improvements for v4.11

/xtensa-20170303 for you to fetch changes up to b46dcfa378b0cdea1ee832802c9e36750e0fffa9: xtensa: allow merging vectors into .text section (2017-03-01 12:32:50 -0800) Xtensa improvements for v4.11: - clean up bootable image build

[PULL 0/3] Xtensa improvements for v4.11

/xtensa-20170303 for you to fetch changes up to b46dcfa378b0cdea1ee832802c9e36750e0fffa9: xtensa: allow merging vectors into .text section (2017-03-01 12:32:50 -0800) Xtensa improvements for v4.11: - clean up bootable image build

[PATCH v4 1/5] staging: nvec: Remove unnecessary cast on void pointer

The following Coccinelle script was used to detect this: @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T*)x)->f | - (T*) e ) Signed-off-by: simran singhal --- drivers/staging/nvec/nvec_kbd.c | 2 +- 1 file changed, 1

[PATCH v4 1/5] staging: nvec: Remove unnecessary cast on void pointer

The following Coccinelle script was used to detect this: @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T*)x)->f | - (T*) e ) Signed-off-by: simran singhal --- drivers/staging/nvec/nvec_kbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

Hi Bjorn, On 03/03/2017 02:33 PM, Bjorn Helgaas wrote: On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: This RFC series provides support for AMD's new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1]. What kernel

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

Hi Bjorn, On 03/03/2017 02:33 PM, Bjorn Helgaas wrote: On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: This RFC series provides support for AMD's new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1]. What kernel

[v5 00/20] x86: Enable User-Mode Instruction Prevention

This is v5 of this series. The four previous submissions can be found here [1], here [2], here[3], and here [4]. This version addresses the comments received in v4 plus improvements of the handling of emulation in 64-bit builds. Please see details in the change log. === What is UMIP? User-Mode

[v5 00/20] x86: Enable User-Mode Instruction Prevention

This is v5 of this series. The four previous submissions can be found here [1], here [2], here[3], and here [4]. This version addresses the comments received in v4 plus improvements of the handling of emulation in 64-bit builds. Please see details in the change log. === What is UMIP? User-Mode

[v5 02/20] x86/mpx: Do not use SIB index if index points to R/ESP

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when memory addressing is used (i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of the SIB byte points to the R/ESP (i.e., index = 4), the index should not be used in the

[v5 02/20] x86/mpx: Do not use SIB index if index points to R/ESP

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when memory addressing is used (i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of the SIB byte points to the R/ESP (i.e., index = 4), the index should not be used in the

[v5 01/20] 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 the r/m part of the ModRM byte, the base and index parts of the SiB byte as well as the displacement. Thus, signed variables shall be used when computing the effective

[v5 07/20] x86/insn-eval: Add utility function to get segment descriptor

The segment descriptor contains information that is relevant to how linear address 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

[v5 01/20] 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 the r/m part of the ModRM byte, the base and index parts of the SiB byte as well as the displacement. Thus, signed variables shall be used when computing the effective

[v5 07/20] x86/insn-eval: Add utility function to get segment descriptor

The segment descriptor contains information that is relevant to how linear address 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

[v5 08/20] x86/insn-eval: Add utility function to get segment descriptor base address

With segmentation, the base address of the segment descriptor is needed to compute a linear address. The segment descriptor used in the address computation depends on either any segment override prefixes in the in the instruction or the default segment determined by the registers involved in the

[v5 08/20] x86/insn-eval: Add utility function to get segment descriptor base address

With segmentation, the base address of the segment descriptor is needed to compute a linear address. The segment descriptor used in the address computation depends on either any segment override prefixes in the in the instruction or the default segment determined by the registers involved in the

[v5 03/20] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when a SIB byte is used and the base of the SIB byte points to R/EBP (i.e., base = 5) and the mod part of the ModRM byte is zero, the value of such register will not be used as part of the

[v5 09/20] x86/insn-eval: Add functions to get default operand and address sizes

These functions read the default values of the address and operand sizes as specified in the segment descriptor. This information is determined from the D and L bits. Hence, it can be used for both IA-32e 64-bit and 32-bit legacy modes. For virtual-8086 mode, the default address and operand sizes

[v5 10/20] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when the mod part of the ModRM byte is zero and R/EBP is specified in the R/M part of such bit, the value of the aforementioned register should not be used in the address computation. Instead,

[v5 03/20] x86/mpx: Do not use R/EBP as base in the SIB byte with Mod = 0

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when a SIB byte is used and the base of the SIB byte points to R/EBP (i.e., base = 5) and the mod part of the ModRM byte is zero, the value of such register will not be used as part of the

[v5 09/20] x86/insn-eval: Add functions to get default operand and address sizes

These functions read the default values of the address and operand sizes as specified in the segment descriptor. This information is determined from the D and L bits. Hence, it can be used for both IA-32e 64-bit and 32-bit legacy modes. For virtual-8086 mode, the default address and operand sizes

[v5 10/20] x86/insn-eval: Do not use R/EBP as base if mod in ModRM is zero

Section 2.2.1.3 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when the mod part of the ModRM byte is zero and R/EBP is specified in the R/M part of such bit, the value of the aforementioned register should not be used in the address computation. Instead,

[v5 15/20] 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

[v5 15/20] 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

[v5 11/20] insn/eval: Incorporate segment base in 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.

[v5 11/20] insn/eval: Incorporate segment base in 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.

[v5 14/20] x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings

Convert the function insn_get_add_ref into a wrapper function that calls the correct static address-decoding function depending on the size of the address. In this way, callers do not need to worry about calling the correct function and decreases the number of functions that need to be exposed.

[v5 13/20] x86/insn-eval: Add support to resolve 16-bit addressing encodings

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

[v5 14/20] x86/insn-eval: Add wrapper function for 16-bit and 32-bit address encodings

Convert the function insn_get_add_ref into a wrapper function that calls the correct static address-decoding function depending on the size of the address. In this way, callers do not need to worry about calling the correct function and decreases the number of functions that need to be exposed.

[v5 13/20] x86/insn-eval: Add support to resolve 16-bit addressing encodings

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

[v5 12/20] x86/insn: Support both signed 32-bit and 64-bit effective addresses

The 32-bit and 64-bit address encodings are identical. This means that we can use the same function in both cases. In order to reuse the function for 32-bit address encodings, we must sign-extend our 32-bit signed operands to 64-bit signed variables (only for 64-bit builds). To decide on whether

[v5 12/20] x86/insn: Support both signed 32-bit and 64-bit effective addresses

The 32-bit and 64-bit address encodings are identical. This means that we can use the same function in both cases. In order to reuse the function for 32-bit address encodings, we must sign-extend our 32-bit signed operands to 64-bit signed variables (only for 64-bit builds). To decide on whether

[v5 16/20] x86: Add emulation code for UMIP instructions

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

[v5 16/20] x86: Add emulation code for UMIP instructions

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

[v5 17/20] 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

[v5 17/20] 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

[v5 18/20] 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,

[v5 18/20] 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,

[v5 20/20] 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

[v5 05/20] x86/insn-eval: Add utility functions to get register offsets

The function insn_get_reg_offset takes as argument an enumeration that indicates the type of offset that is returned: the R/M part of the ModRM byte, the index of the SIB byte or the base of the SIB byte. Callers of this function would need the definition of such enumeration. This is not needed.

[v5 20/20] 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

[v5 05/20] x86/insn-eval: Add utility functions to get register offsets

The function insn_get_reg_offset takes as argument an enumeration that indicates the type of offset that is returned: the R/M part of the ModRM byte, the index of the SIB byte or the base of the SIB byte. Callers of this function would need the definition of such enumeration. This is not needed.

[v5 06/20] 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

[v5 19/20] 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

[v5 06/20] 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

[v5 19/20] 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

[v5 04/20] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel

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

[v5 04/20] x86/mpx, x86/insn: Relocate insn util functions to a new insn-kernel

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

Re: [PATCH v3 03/25] dt-bindings: timer: Document Owl timer

Am 03.03.2017 um 07:20 schrieb Rob Herring: > On Tue, Feb 28, 2017 at 12:39:08PM +, Mark Rutland wrote: >> On Tue, Feb 28, 2017 at 07:35:13AM +0100, Andreas Färber wrote: >>> The Actions Semi S500 SoC contains a timer block with two 2 Hz and two >>> 32-bit timers. The S900 SoC timer block has

Re: [PATCH v3 03/25] dt-bindings: timer: Document Owl timer

Am 03.03.2017 um 07:20 schrieb Rob Herring: > On Tue, Feb 28, 2017 at 12:39:08PM +, Mark Rutland wrote: >> On Tue, Feb 28, 2017 at 07:35:13AM +0100, Andreas Färber wrote: >>> The Actions Semi S500 SoC contains a timer block with two 2 Hz and two >>> 32-bit timers. The S900 SoC timer block has

Re: [PATCH 0/2] fix the traced mt-exec deadlock

ebied...@xmission.com (Eric W. Biederman) writes: > ebied...@xmission.com (Eric W. Biederman) writes: > >> The big lesson for me, and what was not obvious from your change >> description is that we are changing the user space visible semantics >> of exec+ptrace and that cred_guard_mutex is not at

Re: [PATCH 0/2] fix the traced mt-exec deadlock

ebied...@xmission.com (Eric W. Biederman) writes: > ebied...@xmission.com (Eric W. Biederman) writes: > >> The big lesson for me, and what was not obvious from your change >> description is that we are changing the user space visible semantics >> of exec+ptrace and that cred_guard_mutex is not at

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On 3/3/2017 2:42 PM, Bjorn Helgaas wrote: On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: From: Tom Lendacky The use of ioremap will force the setup data to be mapped decrypted even though setup data is encrypted. Switch to using memremap which will be

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On 3/3/2017 2:42 PM, Bjorn Helgaas wrote: On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: From: Tom Lendacky The use of ioremap will force the setup data to be mapped decrypted even though setup data is encrypted. Switch to using memremap which will be able to perform the

Re: [PATCH] zswap: Zero-filled pages handling

On Sat, Feb 25, 2017 at 12:18 PM, Sarbojit Ganguly wrote: > On 25 February 2017 at 20:12, Srividya Desireddy > wrote: >> From: Srividya Desireddy >> Date: Thu, 23 Feb 2017 15:04:06 +0530 >> Subject: [PATCH] zswap:

Re: [PATCH] zswap: Zero-filled pages handling

On Sat, Feb 25, 2017 at 12:18 PM, Sarbojit Ganguly wrote: > On 25 February 2017 at 20:12, Srividya Desireddy > wrote: >> From: Srividya Desireddy >> Date: Thu, 23 Feb 2017 15:04:06 +0530 >> Subject: [PATCH] zswap: Zero-filled pages handling your email is base64-encoded; please send plain text

Re: net/ipv4: division by 0 in tcp_select_window

On Fri, 2017-03-03 at 10:25 -0800, Eric Dumazet wrote: > On Fri, Mar 3, 2017 at 10:10 AM, Dmitry Vyukov wrote: > > Hello, > > > > The following program triggers division by 0 in tcp_select_window: > > > >

Re: net/ipv4: division by 0 in tcp_select_window

On Fri, 2017-03-03 at 10:25 -0800, Eric Dumazet wrote: > On Fri, Mar 3, 2017 at 10:10 AM, Dmitry Vyukov wrote: > > Hello, > > > > The following program triggers division by 0 in tcp_select_window: > > > >

Re: Hundreds of null PATH records for *init_module syscall audit logs

On 2017-02-28 23:15, Steve Grubb wrote: > On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote: > > Sorry, I forgot to include Cc: in this cover letter for context to the 4 > > alt patches. > > > > On 2017-02-28 22:15, Richard Guy Briggs wrote: > > > The background to this is: >

Re: Hundreds of null PATH records for *init_module syscall audit logs

On 2017-02-28 23:15, Steve Grubb wrote: > On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote: > > Sorry, I forgot to include Cc: in this cover letter for context to the 4 > > alt patches. > > > > On 2017-02-28 22:15, Richard Guy Briggs wrote: > > > The background to this is: >

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

Neil Armstrong writes: > Hi Andreas, > On 03/02/2017 01:31 PM, Andreas Färber wrote: >> Hi Neil, >> >> Am 01.03.2017 um 11:46 schrieb Neil Armstrong: >>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs. >> >> First of all, any reason you're upper-casing

Re: [PATCH v2 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL

Neil Armstrong writes: > Hi Andreas, > On 03/02/2017 01:31 PM, Andreas Färber wrote: >> Hi Neil, >> >> Am 01.03.2017 um 11:46 schrieb Neil Armstrong: >>> The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs. >> >> First of all, any reason you're upper-casing Mali in the commit

[bug] regulator: fixed, gpio: probe fails on unset regulator-name

Hi! Documentation/devicetree/bindings/regulator/regulator.txt says that the regulator-name property is optional. However fixed and gpio regulators fail in probe with the following message, if the property is not present: | reg-fixed-voltage regulators:sensor_supply: Failed to allocate supply

[bug] regulator: fixed, gpio: probe fails on unset regulator-name

Hi! Documentation/devicetree/bindings/regulator/regulator.txt says that the regulator-name property is optional. However fixed and gpio regulators fail in probe with the following message, if the property is not present: | reg-fixed-voltage regulators:sensor_supply: Failed to allocate supply

[PATCH] ARM: dts: imx6q-bx50v3/imx6q-b450v3/imx6q-b650v3: fix at25 spi-clk frequency issue

Change the maxium spi clock frequency from 20MHz to 10MHz to meet the operation voltage range requirement recommended in AT25 datasheet Signed-off-by: Ken Lin --- arch/arm/boot/dts/imx6q-bx50v3.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] ARM: dts: imx6q-bx50v3/imx6q-b450v3/imx6q-b650v3: fix at25 spi-clk frequency issue

Change the maxium spi clock frequency from 20MHz to 10MHz to meet the operation voltage range requirement recommended in AT25 datasheet Signed-off-by: Ken Lin --- arch/arm/boot/dts/imx6q-bx50v3.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] staging: ks7010: clean up code

This fixes type warnings generated by sparse, replaces instances of ntohs() with be16_to_cpu() and removes unused fields in structs. Signed-off-by: Ernestas Kulik --- drivers/staging/ks7010/ks7010_sdio.c | 12 ++-- drivers/staging/ks7010/ks_hostif.c | 30 +

[PATCH] staging: ks7010: clean up code

This fixes type warnings generated by sparse, replaces instances of ntohs() with be16_to_cpu() and removes unused fields in structs. Signed-off-by: Ernestas Kulik --- drivers/staging/ks7010/ks7010_sdio.c | 12 ++-- drivers/staging/ks7010/ks_hostif.c | 30 +

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

Hi Boris, On 03/03/2017 10:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote: From: Tom Lendacky Update the CPU features to include identifying and reporting on the Secure Encrypted Virtualization (SEV) feature. SME is

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

Hi Boris, On 03/03/2017 10:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote: From: Tom Lendacky Update the CPU features to include identifying and reporting on the Secure Encrypted Virtualization (SEV) feature. SME is identified by CPUID

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote: > On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > > This RFC series provides support for AMD's new Secure Encrypted > > Virtualization > > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 >

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote: > On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > > This RFC series provides support for AMD's new Secure Encrypted > > Virtualization > > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 >

Re: [RFC] arm64: support HAVE_ARCH_RARE_WRITE

On Thu, Mar 2, 2017 at 7:00 AM, Hoeun Ryu wrote: > +unsigned long __rare_write_rw_alias_start = TASK_SIZE_64 / 4; > + > +__always_inline unsigned long __arch_rare_write_map(void) > +{ > + struct mm_struct *mm = _write_mm; > + > + preempt_disable(); > + > +

Re: [RFC] arm64: support HAVE_ARCH_RARE_WRITE

On Thu, Mar 2, 2017 at 7:00 AM, Hoeun Ryu wrote: > +unsigned long __rare_write_rw_alias_start = TASK_SIZE_64 / 4; > + > +__always_inline unsigned long __arch_rare_write_map(void) > +{ > + struct mm_struct *mm = _write_mm; > + > + preempt_disable(); > + > + __switch_mm(mm); ...

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The use of ioremap will force the setup data to be mapped decrypted even > though setup data is encrypted. Switch to using memremap which will be > able to perform the proper

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The use of ioremap will force the setup data to be mapped decrypted even > though setup data is encrypted. Switch to using memremap which will be > able to perform the proper mapping. How should callers

Re: [PATCH] dt-bindings: display: rk3288-mipi-dsi: add reset property

On Fri, Mar 03, 2017 at 11:39:45AM +, John Keeping wrote: > This reset is required in order to fully reset the internal state of the > MIPI controller. > > Signed-off-by: John Keeping > --- > On Thu, 2 Mar 2017 13:56:46 -0800, Brian Norris wrote: > > On Fri, Feb 24, 2017

Re: [PATCH] dt-bindings: display: rk3288-mipi-dsi: add reset property

On Fri, Mar 03, 2017 at 11:39:45AM +, John Keeping wrote: > This reset is required in order to fully reset the internal state of the > MIPI controller. > > Signed-off-by: John Keeping > --- > On Thu, 2 Mar 2017 13:56:46 -0800, Brian Norris wrote: > > On Fri, Feb 24, 2017 at 12:55:06PM +,

[PATCH 05/10] Replaced pr_err by dev_err. Modified debug message

Signed-off-by: Ryan Lee --- Replaced 'pr_err' by 'dev_err'. Modified error message. sound/soc/codecs/max98927.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index

[PATCH 05/10] Replaced pr_err by dev_err. Modified debug message

Signed-off-by: Ryan Lee --- Replaced 'pr_err' by 'dev_err'. Modified error message. sound/soc/codecs/max98927.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c index efc761b..0abf6d3 100755 ---

[PATCH 06/10] Added mask variable to apply it in one round after the switch

Signed-off-by: Ryan Lee --- Added the mask variable to apply in one round after the switch. sound/soc/codecs/max98927.c | 64 ++--- 1 file changed, 31 insertions(+), 33 deletions(-) diff --git a/sound/soc/codecs/max98927.c

[PATCH 06/10] Added mask variable to apply it in one round after the switch

Signed-off-by: Ryan Lee --- Added the mask variable to apply in one round after the switch. sound/soc/codecs/max98927.c | 64 ++--- 1 file changed, 31 insertions(+), 33 deletions(-) diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > This RFC series provides support for AMD's new Secure Encrypted Virtualization > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 > [1]. What kernel version is this series based on?

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > This RFC series provides support for AMD's new Secure Encrypted Virtualization > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 > [1]. What kernel version is this series based on?

<    1   2   3   4   5   6   7   8   9   10   >