Re: [PATCH] pci: hotplug: This patch removes unnecessary return statement using spatch tool

On Sat, 2016-12-24 at 13:03 +0530, Rahul Krishnan wrote: > This patch removes unnecessary return statement using spatch tool [] > diff --git a/drivers/pci/hotplug/rpadlpar_core.c > b/drivers/pci/hotplug/rpadlpar_core.c [] > @@ -463,8 +463,7 @@ int __init rpadlpar_io_init(void) >

Re: [PATCH] pci: hotplug: This patch removes unnecessary return statement using spatch tool

On Sat, 2016-12-24 at 13:03 +0530, Rahul Krishnan wrote: > This patch removes unnecessary return statement using spatch tool [] > diff --git a/drivers/pci/hotplug/rpadlpar_core.c > b/drivers/pci/hotplug/rpadlpar_core.c [] > @@ -463,8 +463,7 @@ int __init rpadlpar_io_init(void) >

Re: [PATCH] ACPI: Remove misplaced acpi_dma_deconfigure() call in acpi_bind_one()

On 2016/12/16 22:43, Lorenzo Pieralisi wrote: > The acpi_bind_one() error return path can be hit either on physical node > allocation failure or if the device being configured is already > associated with an ACPI node and its ACPI companion does not match the > one acpi_bind_one() is setting it up

Re: [PATCH] ACPI: Remove misplaced acpi_dma_deconfigure() call in acpi_bind_one()

On 2016/12/16 22:43, Lorenzo Pieralisi wrote: > The acpi_bind_one() error return path can be hit either on physical node > allocation failure or if the device being configured is already > associated with an ACPI node and its ACPI companion does not match the > one acpi_bind_one() is setting it up

Re: [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device

Hi Rafael, Thank you for your comments, when I was demoing your suggestion, I got a little bit confusions, please see my comments below. On 2016/12/22 20:57, Rafael J. Wysocki wrote: > On Thu, Dec 22, 2016 at 6:35 AM, Hanjun Guo wrote: >> From: Hanjun Guo

Re: [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device

Hi Rafael, Thank you for your comments, when I was demoing your suggestion, I got a little bit confusions, please see my comments below. On 2016/12/22 20:57, Rafael J. Wysocki wrote: > On Thu, Dec 22, 2016 at 6:35 AM, Hanjun Guo wrote: >> From: Hanjun Guo >> >> With the platform msi domain

[PATCH] pci: hotplug: This patch removes unnecessary return statement using spatch tool

This patch removes unnecessary return statement using spatch tool Signed-off-by: Rahul Krishnan --- drivers/pci/hotplug/rpadlpar_core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/pci/hotplug/rpadlpar_core.c

[PATCH] pci: hotplug: This patch removes unnecessary return statement using spatch tool

This patch removes unnecessary return statement using spatch tool Signed-off-by: Rahul Krishnan --- drivers/pci/hotplug/rpadlpar_core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c index

Re: [PATCH] serial: 8250: use initializer instead of memset to clear local struct

Hi Greg, 2016-12-23 16:20 GMT+09:00 Greg Kroah-Hartman : > On Fri, Dec 23, 2016 at 12:21:48PM +0900, Masahiro Yamada wrote: >> Leave the way of zero-out to the compiler's decision; the compiler >> may know a more optimized way than calling memset(). > > But no, it

Re: [PATCH] serial: 8250: use initializer instead of memset to clear local struct

Hi Greg, 2016-12-23 16:20 GMT+09:00 Greg Kroah-Hartman : > On Fri, Dec 23, 2016 at 12:21:48PM +0900, Masahiro Yamada wrote: >> Leave the way of zero-out to the compiler's decision; the compiler >> may know a more optimized way than calling memset(). > > But no, it doesn't, it will leave "blank"

Re: [PATCH] find_bit: Micro-optimise find_next_*_bit

Hi Mattew, On Fri, Dec 23, 2016 at 09:20:03AM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox > > This saves 20 bytes on my x86-64 build, mostly due to alignment > considerations ... I think it actually saves about five bytes of > instructions. There's really two

Re: [PATCH] find_bit: Micro-optimise find_next_*_bit

Hi Mattew, On Fri, Dec 23, 2016 at 09:20:03AM -0800, Matthew Wilcox wrote: > From: Matthew Wilcox > > This saves 20 bytes on my x86-64 build, mostly due to alignment > considerations ... I think it actually saves about five bytes of > instructions. There's really two parts to this commit.

Re: [PATCH] tools build: replace $(CC) -E with $(CPP) for pre-processing

Hi Jiri, 2016-12-23 19:59 GMT+09:00 Jiri Olsa : > On Fri, Dec 23, 2016 at 01:46:42PM +0900, Masahiro Yamada wrote: >> The top-level Makefile defines: >> >> CPP = $(CC) -E > > hum, so that'd work for running from top level, but I guess > it fails for compiling from

Re: [PATCH] tools build: replace $(CC) -E with $(CPP) for pre-processing

Hi Jiri, 2016-12-23 19:59 GMT+09:00 Jiri Olsa : > On Fri, Dec 23, 2016 at 01:46:42PM +0900, Masahiro Yamada wrote: >> The top-level Makefile defines: >> >> CPP = $(CC) -E > > hum, so that'd work for running from top level, but I guess > it fails for compiling from other places..?

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On Fri, 23 Dec 2016, Guenter Roeck wrote: > Hi Julia, > > On Fri, Dec 23, 2016 at 04:54:41PM +0100, Julia Lawall wrote: > [ ... ] > > > > // - > > @ro@ > > declarer name SENSOR_DEVICE_ATTR, SENSOR_DEVICE_ATTR_2; > >

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On Fri, 23 Dec 2016, Guenter Roeck wrote: > Hi Julia, > > On Fri, Dec 23, 2016 at 04:54:41PM +0100, Julia Lawall wrote: > [ ... ] > > > > // - > > @ro@ > > declarer name SENSOR_DEVICE_ATTR, SENSOR_DEVICE_ATTR_2; > >

Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

On Wed, Dec 21, 2016 at 11:18:34PM -0500, Geoff Lansberry wrote: > From: Jaret Cantu > > Repeated polling attempts cause a NULL dereference error to occur. > This is because the state of the trf7970a is currently reading but > another request has been made to send a

Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel

On Wed, Dec 21, 2016 at 11:18:34PM -0500, Geoff Lansberry wrote: > From: Jaret Cantu > > Repeated polling attempts cause a NULL dereference error to occur. > This is because the state of the trf7970a is currently reading but > another request has been made to send a command before it has

[PATCH v2] scsi: bfa: Increase requested firmware version to 3.2.5.1

bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR Series Adapter Firmware"). bna was updated to use the newer firmware on Feb 19 16:02:32 2015 -0500 in 3f307c3d70 ("bna: Update the Driver and Firmware

[PATCH v2] scsi: bfa: Increase requested firmware version to 3.2.5.1

bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR Series Adapter Firmware"). bna was updated to use the newer firmware on Feb 19 16:02:32 2015 -0500 in 3f307c3d70 ("bna: Update the Driver and Firmware

FOSSASIA'17 Kernel Track: Call for Speakers

Dear Linux Kernel developers, The FOSSASIA 2017 Kernel Track would like to welcome all interested speakers to submit abstracts for presentations. You'll have the opportunity to share your knowledge and discuss with like-minded individuals, representing a broad range of industries and

FOSSASIA'17 Kernel Track: Call for Speakers

Dear Linux Kernel developers, The FOSSASIA 2017 Kernel Track would like to welcome all interested speakers to submit abstracts for presentations. You'll have the opportunity to share your knowledge and discuss with like-minded individuals, representing a broad range of industries and

Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

Hi Ricardo, [auto build test ERROR on tip/auto-latest] [also build test ERROR on next-20161223] [cannot apply to tip/x86/core v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo-Neri

Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

Hi Ricardo, [auto build test ERROR on tip/auto-latest] [also build test ERROR on next-20161223] [cannot apply to tip/x86/core v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo-Neri

linux-next: Tree for Dec 24

Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. There will be no linux-next releases from me between Dec 25 and Jan 2 inclusive (unless I get really bored with my new toys :-)). Changes since 20161223: Non-merge

linux-next: Tree for Dec 24

Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. There will be no linux-next releases from me between Dec 25 and Jan 2 inclusive (unless I get really bored with my new toys :-)). Changes since 20161223: Non-merge

Re: [PATCH v7 00/12] Fix kdump faults on system with amd iommu

Hi Joerg, Ping! Could you help review this version? Not sure this could catch up to v4.10 merging. Thanks Baoqaun On 11/25/16 at 01:13pm, Baoquan He wrote: > This is v7 post. > > The principle of the fix is similar to intel iommu. Just defer the assignment > of device to domain to device

Re: [PATCH v7 00/12] Fix kdump faults on system with amd iommu

Hi Joerg, Ping! Could you help review this version? Not sure this could catch up to v4.10 merging. Thanks Baoqaun On 11/25/16 at 01:13pm, Baoquan He wrote: > This is v7 post. > > The principle of the fix is similar to intel iommu. Just defer the assignment > of device to domain to device

Re: [v2 7/7] x86: Enable User-Mode Instruction Prevention

Hi Ricardo, [auto build test WARNING on tip/auto-latest] [also build test WARNING on next-20161223] [cannot apply to tip/x86/core v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo

Re: [v2 7/7] x86: Enable User-Mode Instruction Prevention

Hi Ricardo, [auto build test WARNING on tip/auto-latest] [also build test WARNING on next-20161223] [cannot apply to tip/x86/core v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On 12/23/2016 12:42 PM, Linus Torvalds wrote: > On Fri, Dec 23, 2016 at 2:00 AM, Christoph Hellwig wrote: >> >> From: Christoph Hellwig >> Date: Fri, 23 Dec 2016 10:57:06 +0100 >> Subject: virtio_blk: avoid DMA to stack for the sense buffer >> >> Most users of BLOCK_PC

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On 12/23/2016 12:42 PM, Linus Torvalds wrote: > On Fri, Dec 23, 2016 at 2:00 AM, Christoph Hellwig wrote: >> >> From: Christoph Hellwig >> Date: Fri, 23 Dec 2016 10:57:06 +0100 >> Subject: virtio_blk: avoid DMA to stack for the sense buffer >> >> Most users of BLOCK_PC requests allocate the

Re: [v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils

Hi Ricardo, [auto build test WARNING on tip/auto-latest] [also build test WARNING on v4.9 next-20161223] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo

Re: [v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils

Hi Ricardo, [auto build test WARNING on tip/auto-latest] [also build test WARNING on v4.9 next-20161223] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ricardo

Re: [PATCH] adc: add adc driver for Hisilicon BVT SOCs

On 2016/12/24 9:54, Allen Liu wrote: > Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like > Hi3516CV300, etc. > The ADC controller is primarily in charge of detecting voltage. > > Reviewed-by: Jiancheng Xue Hi Sorry. I haven't reviewed this

Re: [PATCH] adc: add adc driver for Hisilicon BVT SOCs

On 2016/12/24 9:54, Allen Liu wrote: > Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like > Hi3516CV300, etc. > The ADC controller is primarily in charge of detecting voltage. > > Reviewed-by: Jiancheng Xue Hi Sorry. I haven't reviewed this patch. Please remove this

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Fri, Dec 23, 2016 at 6:22 PM, Andy Lutomirski wrote: > There are some pieecs of kernel code that want to compute SHA256 > directly without going through the crypto core. Adjust the exported > API to decouple it from the crypto core. > > I suspect this will very slightly speed

Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

On Fri, Dec 23, 2016 at 6:22 PM, Andy Lutomirski wrote: > There are some pieecs of kernel code that want to compute SHA256 > directly without going through the crypto core. Adjust the exported > API to decouple it from the crypto core. > > I suspect this will very slightly speed up the SHA256

[RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

There are some pieecs of kernel code that want to compute SHA256 directly without going through the crypto core. Adjust the exported API to decouple it from the crypto core. I suspect this will very slightly speed up the SHA256 shash operations as well by reducing the amount of indirection

[RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash

There are some pieecs of kernel code that want to compute SHA256 directly without going through the crypto core. Adjust the exported API to decouple it from the crypto core. I suspect this will very slightly speed up the SHA256 shash operations as well by reducing the amount of indirection

[RFC PATCH 4.10 3/6] bpf: Use SHA256 instead of SHA1 for bpf digests

BPF digests are intended to be used to avoid reloading programs that are already loaded. For use cases (CRIU?) where untrusted programs are involved, intentional hash collisions could cause the wrong BPF program to execute. Additionally, if BPF digests are ever used in-kernel to skip

[RFC PATCH 4.10 3/6] bpf: Use SHA256 instead of SHA1 for bpf digests

BPF digests are intended to be used to avoid reloading programs that are already loaded. For use cases (CRIU?) where untrusted programs are involved, intentional hash collisions could cause the wrong BPF program to execute. Additionally, if BPF digests are ever used in-kernel to skip

[RFC PATCH 4.10 2/6] crypto/sha256: Make the sha256 library functions selectable

This will let other kernel code call into sha256_init(), etc. without pulling in the core crypto code. Signed-off-by: Andy Lutomirski --- crypto/Kconfig | 8 crypto/Makefile | 2 +- crypto/sha256_generic.c | 4 include/crypto/sha.h| 4 4

[RFC PATCH 4.10 4/6] bpf: Avoid copying the entire BPF program when hashing it

The sha256 helpers can consume a message incrementally, so there's no need to allocate a buffer to store the whole blob to be hashed. This may be a slight slowdown for very long messages because gcc can't inline the sha256_update() calls. For reasonably-sized programs, however, this should be a

[RFC PATCH 4.10 6/6] net: Rename TCA*BPF_DIGEST to ..._SHA256

This makes it easier to add another digest algorithm down the road if needed. It also serves to force any programs that might have been written against a kernel that had the old field name to notice the change and make any necessary changes. This shouldn't violate any stable API policies, as no

[RFC PATCH 4.10 2/6] crypto/sha256: Make the sha256 library functions selectable

This will let other kernel code call into sha256_init(), etc. without pulling in the core crypto code. Signed-off-by: Andy Lutomirski --- crypto/Kconfig | 8 crypto/Makefile | 2 +- crypto/sha256_generic.c | 4 include/crypto/sha.h| 4 4 files changed, 17

[RFC PATCH 4.10 4/6] bpf: Avoid copying the entire BPF program when hashing it

The sha256 helpers can consume a message incrementally, so there's no need to allocate a buffer to store the whole blob to be hashed. This may be a slight slowdown for very long messages because gcc can't inline the sha256_update() calls. For reasonably-sized programs, however, this should be a

[RFC PATCH 4.10 6/6] net: Rename TCA*BPF_DIGEST to ..._SHA256

This makes it easier to add another digest algorithm down the road if needed. It also serves to force any programs that might have been written against a kernel that had the old field name to notice the change and make any necessary changes. This shouldn't violate any stable API policies, as no

[RFC PATCH 4.10 5/6] bpf: Rename fdinfo's prog_digest to prog_sha256

This makes it easier to add another digest algorithm down the road if needed. It also serves to force any programs that might have been written against a kernel that had 'prog_digest' to be updated. This shouldn't violate any stable API policies, as no released kernel has ever had 'prog_digest'.

[RFC PATCH 4.10 5/6] bpf: Rename fdinfo's prog_digest to prog_sha256

This makes it easier to add another digest algorithm down the road if needed. It also serves to force any programs that might have been written against a kernel that had 'prog_digest' to be updated. This shouldn't violate any stable API policies, as no released kernel has ever had 'prog_digest'.

[RFC PATCH 4.10 0/6] Switch BPF's digest to SHA256

Since there are plenty of uses for the new-in-4.10 BPF digest feature that would be problematic if malicious users could produce collisions, the BPF digest should be collision-resistant. SHA-1 is no longer considered collision-resistant, so switch it to SHA-256. The actual switchover is trivial.

[RFC PATCH 4.10 0/6] Switch BPF's digest to SHA256

Since there are plenty of uses for the new-in-4.10 BPF digest feature that would be problematic if malicious users could produce collisions, the BPF digest should be collision-resistant. SHA-1 is no longer considered collision-resistant, so switch it to SHA-256. The actual switchover is trivial.

Re: [PATCH v2 4/4] clk: rockchip: add new pll-type for rk3328

Hi Elaine, Am Montag, 19. Dezember 2016, 09:56:13 CET schrieb Elaine Zhang: > The rk3328's pll and clock are similar with rk3036's, > it different with pll_mode_mask,there are different > control registers bit, > so these should be independent and separate from > the series of rk3328s. not sure

Re: [PATCH v2 4/4] clk: rockchip: add new pll-type for rk3328

Hi Elaine, Am Montag, 19. Dezember 2016, 09:56:13 CET schrieb Elaine Zhang: > The rk3328's pll and clock are similar with rk3036's, > it different with pll_mode_mask,there are different > control registers bit, > so these should be independent and separate from > the series of rk3328s. not sure

Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri wrote: > 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

Re: [v2 5/7] x86: Add emulation code for UMIP instructions

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri wrote: > 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. > >

Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri wrote: > 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

Re: [v2 5/7] x86: Add emulation code for UMIP instructions

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri wrote: > 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

Re: [v2 1/7] x86/mpx: Do not use SIB index if index points to R/ESP

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri wrote: > 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

Re: [v2 1/7] x86/mpx: Do not use SIB index if index points to R/ESP

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri wrote: > 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

Re: [v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri wrote: > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software > Developer's Manual volume 2A states that when memory addressing with no > explicit displacement (i.e, mod part of ModR/M is 0), a SIB

Re: [v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri wrote: > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software > Developer's Manual volume 2A states that when memory addressing with no > explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used > and the base of the SIB

[PATCH] adc: add adc driver for Hisilicon BVT SOCs

Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like Hi3516CV300, etc. The ADC controller is primarily in charge of detecting voltage. Reviewed-by: Jiancheng Xue Signed-off-by: Allen Liu ---

[PATCH] adc: add adc driver for Hisilicon BVT SOCs

Add ADC driver for the ADC controller found on HiSilicon BVT SOCs, like Hi3516CV300, etc. The ADC controller is primarily in charge of detecting voltage. Reviewed-by: Jiancheng Xue Signed-off-by: Allen Liu --- .../devicetree/bindings/iio/adc/hibvt-lsadc.txt| 26 ++

[v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when memory addressing with no explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used and the base of the SIB byte points to (R/EBP) (i.e., base = 5), an explicit

[v2 1/7] 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

[v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP

Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software Developer's Manual volume 2A states that when memory addressing with no explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used and the base of the SIB byte points to (R/EBP) (i.e., base = 5), an explicit

[v2 1/7] 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

[v2 5/7] 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

[v2 7/7] 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

[v2 6/7] 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,

[v2 5/7] 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

[v2 7/7] 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

[v2 6/7] 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,

[v2 0/7] x86: enable User-Mode Instruction Prevention

This is v2 of my first submission done a while ago[1]. I apologize for the delay. User-Mode Instruction Prevention (UMIP) is a security feature present in new Intel Processors. If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0. If

[v2 4/7] 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

[v2 0/7] x86: enable User-Mode Instruction Prevention

This is v2 of my first submission done a while ago[1]. I apologize for the delay. User-Mode Instruction Prevention (UMIP) is a security feature present in new Intel Processors. If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0. If

[v2 4/7] 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

[v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils

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

[v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils

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] irqchip: keystone: Fix "scheduling while atomic" on rt

Hi Grygorii, On 12/08/2016 05:33 PM, Grygorii Strashko wrote: > From: "Strashko, Grygorii" > > The below call chain generates "scheduling while atomic" backtrace and > causes system crash when Keystone 2 IRQ chip driver is used with RT-kernel: > > gic_handle_irq() >

Re: [PATCH] irqchip: keystone: Fix "scheduling while atomic" on rt

Hi Grygorii, On 12/08/2016 05:33 PM, Grygorii Strashko wrote: > From: "Strashko, Grygorii" > > The below call chain generates "scheduling while atomic" backtrace and > causes system crash when Keystone 2 IRQ chip driver is used with RT-kernel: > > gic_handle_irq() > |-__handle_domain_irq() >

Re: [PATCH] drivers: net: ethernet: 3com: fix return value

On Sat, 2016-12-24 at 00:00 +0100, Thomas Preisner wrote: > diff --git a/drivers/net/ethernet/3com/typhoon.c > b/drivers/net/ethernet/3com/typhoon.c > index a0cacbe..9a3ab58 100644 > --- a/drivers/net/ethernet/3com/typhoon.c > +++ b/drivers/net/ethernet/3com/typhoon.c > @@ -2404,6 +2404,7 @@

Re: [PATCH] drivers: net: ethernet: 3com: fix return value

On Sat, 2016-12-24 at 00:00 +0100, Thomas Preisner wrote: > diff --git a/drivers/net/ethernet/3com/typhoon.c > b/drivers/net/ethernet/3com/typhoon.c > index a0cacbe..9a3ab58 100644 > --- a/drivers/net/ethernet/3com/typhoon.c > +++ b/drivers/net/ethernet/3com/typhoon.c > @@ -2404,6 +2404,7 @@

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hannes Frederic Sowa wrote: > On 24.12.2016 00:39, George Spelvin wrote: >> We just finished discussing why 8 bytes isn't enough. If you only >> feed back 8 bytes, an attacker who can do 2^64 computation can find it >> (by guessing and computing forward to verify the guess) and recover the >>

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hannes Frederic Sowa wrote: > On 24.12.2016 00:39, George Spelvin wrote: >> We just finished discussing why 8 bytes isn't enough. If you only >> feed back 8 bytes, an attacker who can do 2^64 computation can find it >> (by guessing and computing forward to verify the guess) and recover the >>

RE: [PATCH] scsi: bfa: Increase requested firmware version to 3.2.5.1

> From: Benjamin Poirier [mailto:benjamin.poir...@gmail.com] On Behalf Of > Benjamin Poirier > Sent: Friday, December 23, 2016 2:01 PM > > bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on Tue > Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR > Series

RE: [PATCH] scsi: bfa: Increase requested firmware version to 3.2.5.1

> From: Benjamin Poirier [mailto:benjamin.poir...@gmail.com] On Behalf Of > Benjamin Poirier > Sent: Friday, December 23, 2016 2:01 PM > > bna & bfa firmware version 3.2.5.1 was submitted to linux-firmware on Tue > Feb 17 19:10:20 2015 -0500 in 0ab54ff1dc ("linux-firmware: Add QLogic BR > Series

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hi, On 24.12.2016 00:39, George Spelvin wrote: > Hannes Frederic Sowa wrote: >> In general this looks good, but bitbuffer needs to be protected from >> concurrent access, thus needing at least some atomic instruction and >> disabling of interrupts for the locking if done outside of >>

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hi, On 24.12.2016 00:39, George Spelvin wrote: > Hannes Frederic Sowa wrote: >> In general this looks good, but bitbuffer needs to be protected from >> concurrent access, thus needing at least some atomic instruction and >> disabling of interrupts for the locking if done outside of >>

Re: [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature

On 12/23/2016 11:05 AM, Suman Anna wrote: > Hi Sarang, > >>> >>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote: The function wkup_m3_rproc_boot_thread waits for asynchronous firmware loading to complete successfully before calling rproc_boot(). The same can be achieved by just

Re: [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature

On 12/23/2016 11:05 AM, Suman Anna wrote: > Hi Sarang, > >>> >>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote: The function wkup_m3_rproc_boot_thread waits for asynchronous firmware loading to complete successfully before calling rproc_boot(). The same can be achieved by just

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hannes Frederic Sowa wrote: > In general this looks good, but bitbuffer needs to be protected from > concurrent access, thus needing at least some atomic instruction and > disabling of interrupts for the locking if done outside of > get_random_long. Thus I liked your previous approach more where

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hannes Frederic Sowa wrote: > In general this looks good, but bitbuffer needs to be protected from > concurrent access, thus needing at least some atomic instruction and > disabling of interrupts for the locking if done outside of > get_random_long. Thus I liked your previous approach more where

[PATCH] cpufreq: intel_pstate: Do not expose PID parameters in passive mode

From: Rafael J. Wysocki If intel_pstate works in the passive mode in which it acts as a regular cpufreq driver and collaborates with generic cpufreq governors, the PID parameters are not used, so do not expose them via debugfs in that case. Signed-off-by: Rafael J.

[PATCH] cpufreq: intel_pstate: Do not expose PID parameters in passive mode

From: Rafael J. Wysocki If intel_pstate works in the passive mode in which it acts as a regular cpufreq driver and collaborates with generic cpufreq governors, the PID parameters are not used, so do not expose them via debugfs in that case. Signed-off-by: Rafael J. Wysocki ---

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

Hi Julia, On Fri, Dec 23, 2016 at 04:54:41PM +0100, Julia Lawall wrote: [ ... ] > > // - > @ro@ > declarer name SENSOR_DEVICE_ATTR, SENSOR_DEVICE_ATTR_2; > identifier x,show; > @@ > >

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

Hi Julia, On Fri, Dec 23, 2016 at 04:54:41PM +0100, Julia Lawall wrote: [ ... ] > > // - > @ro@ > declarer name SENSOR_DEVICE_ATTR, SENSOR_DEVICE_ATTR_2; > identifier x,show; > @@ > >

[PATCH] drivers: net: ethernet: 3com: fix return value

In a few cases the err-variable is not set to a negative error code if a function call fails and thus 0 is returned instead. It may be better to set err to the proper negative error code before returning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841 Reported-by: Pan Bian

[PATCH] drivers: net: ethernet: 3com: fix return value

In a few cases the err-variable is not set to a negative error code if a function call fails and thus 0 is returned instead. It may be better to set err to the proper negative error code before returning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188841 Reported-by: Pan Bian

  1   2   3   4   5   6   >