Re: smpboot seems to be confused on dual EPYC system

On Sun, May 20, 2018 at 03:23:32PM +0200, Gabriel C wrote: > Hello, > > I have an H11DSi-NT board with 2 * EPYC 7281 16C/32T CPUs. > > On that box for some reason spmboot things '4' logical packages > are possible. First of all, which kernel? > Max CPUs can be 128 ( 2 * 32C/64T ), however

Re: smpboot seems to be confused on dual EPYC system

On Sun, May 20, 2018 at 03:23:32PM +0200, Gabriel C wrote: > Hello, > > I have an H11DSi-NT board with 2 * EPYC 7281 16C/32T CPUs. > > On that box for some reason spmboot things '4' logical packages > are possible. First of all, which kernel? > Max CPUs can be 128 ( 2 * 32C/64T ), however

KASAN: use-after-free Write in bpf_tcp_close

Hello, syzbot found the following crash on: HEAD commit:ff4fb475cea8 Merge branch 'btf-uapi-cleanups' git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=12b3d57780 kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1 dashboard link:

KASAN: use-after-free Write in bpf_tcp_close

Hello, syzbot found the following crash on: HEAD commit:ff4fb475cea8 Merge branch 'btf-uapi-cleanups' git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=12b3d57780 kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1 dashboard link:

[tip:x86/microcode] x86/microcode: Make the late update update_lock a raw lock for RT

Commit-ID: ff987fcf011d20c53b3a613edf6e2055ea48e26e Gitweb: https://git.kernel.org/tip/ff987fcf011d20c53b3a613edf6e2055ea48e26e Author: Scott Wood AuthorDate: Thu, 24 May 2018 10:44:20 -0500 Committer: Thomas Gleixner CommitDate: Sun, 27 May 2018

[tip:x86/microcode] x86/microcode: Make the late update update_lock a raw lock for RT

Commit-ID: ff987fcf011d20c53b3a613edf6e2055ea48e26e Gitweb: https://git.kernel.org/tip/ff987fcf011d20c53b3a613edf6e2055ea48e26e Author: Scott Wood AuthorDate: Thu, 24 May 2018 10:44:20 -0500 Committer: Thomas Gleixner CommitDate: Sun, 27 May 2018 21:50:09 +0200 x86/microcode: Make the

[PATCH] ARM: pxa: add the missing AC97 clocks

The AC97 bit clock is added as the pxa internally generated 13MHz clock. This is a consequence of the new ac97 framework. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/devices.c | 13 + 1 file changed, 13 insertions(+) diff --git

[PATCH] ARM: pxa: add the missing AC97 clocks

The AC97 bit clock is added as the pxa internally generated 13MHz clock. This is a consequence of the new ac97 framework. Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/devices.c | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/mach-pxa/devices.c

[PATCH] ARM: pxa: mioa701 convert to the new AC97 bus

This migration implies : - wm9713 device is removed, it will be auto-probed Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/mioa701.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c index

[PATCH] ARM: pxa: mioa701 convert to the new AC97 bus

This migration implies : - wm9713 device is removed, it will be auto-probed Signed-off-by: Robert Jarzmik --- arch/arm/mach-pxa/mioa701.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c index 9b6c7ea45a40..04dc78d0809f 100644 ---

Re: linux-next: Tree for May 24

Hi Mark, On Sun, 27 May 2018 19:46:39 +0100 Mark Brown wrote: > > On Fri, May 25, 2018 at 06:30:25PM +0100, Mark Brown wrote: > > > quickly as hoped, sorry. There should be another linux-next done by me > > for today (25th) as well, that will appear tomorrow all being well.

Re: linux-next: Tree for May 24

Hi Mark, On Sun, 27 May 2018 19:46:39 +0100 Mark Brown wrote: > > On Fri, May 25, 2018 at 06:30:25PM +0100, Mark Brown wrote: > > > quickly as hoped, sorry. There should be another linux-next done by me > > for today (25th) as well, that will appear tomorrow all being well. Thanks for

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

On 27.05.2018 21:01, Gerhard Wiesinger wrote: On 24.05.2018 08:22, Gerhard Wiesinger wrote: On 24.05.2018 07:29, Gerhard Wiesinger wrote: After some analysis with Florian (thnx) we found out that the current implementation is broken: https://patchwork.ozlabs.org/patch/836538/

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

On 27.05.2018 21:01, Gerhard Wiesinger wrote: On 24.05.2018 08:22, Gerhard Wiesinger wrote: On 24.05.2018 07:29, Gerhard Wiesinger wrote: After some analysis with Florian (thnx) we found out that the current implementation is broken: https://patchwork.ozlabs.org/patch/836538/

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

On 27.05.2018 18:30, Boris Brezillon wrote: > On Sun, 27 May 2018 17:54:03 +0200 > Miquel Raynal wrote: > >> Hi Boris, >> >> On Sun, 27 May 2018 17:13:37 +0200, Boris Brezillon >> wrote: >> >> > On Sun, 27 May 2018 16:18:32 +0200 >> >

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

On 27.05.2018 18:30, Boris Brezillon wrote: > On Sun, 27 May 2018 17:54:03 +0200 > Miquel Raynal wrote: > >> Hi Boris, >> >> On Sun, 27 May 2018 17:13:37 +0200, Boris Brezillon >> wrote: >> >> > On Sun, 27 May 2018 16:18:32 +0200 >> > Miquel Raynal wrote: >> > >> > > Hi Stefan, >> > > >> > >

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

On 24.05.2018 08:22, Gerhard Wiesinger wrote: On 24.05.2018 07:29, Gerhard Wiesinger wrote: After some analysis with Florian (thnx) we found out that the current implementation is broken: https://patchwork.ozlabs.org/patch/836538/

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

On 24.05.2018 08:22, Gerhard Wiesinger wrote: On 24.05.2018 07:29, Gerhard Wiesinger wrote: After some analysis with Florian (thnx) we found out that the current implementation is broken: https://patchwork.ozlabs.org/patch/836538/

Re: linux-next: Tree for May 24

On Fri, May 25, 2018 at 06:30:25PM +0100, Mark Brown wrote: > quickly as hoped, sorry. There should be another linux-next done by me > for today (25th) as well, that will appear tomorrow all being well. There won't be. For some reason I need to get to the bottom of the builds are taking a lot

Re: linux-next: Tree for May 24

On Fri, May 25, 2018 at 06:30:25PM +0100, Mark Brown wrote: > quickly as hoped, sorry. There should be another linux-next done by me > for today (25th) as well, that will appear tomorrow all being well. There won't be. For some reason I need to get to the bottom of the builds are taking a lot

Re: linux-next: manual merge of the userns tree with the arm tree

On Sun, May 27, 2018 at 01:29:55PM -0500, Eric W. Biederman wrote: > Mark Brown writes: > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your

Re: linux-next: manual merge of the userns tree with the arm tree

On Sun, May 27, 2018 at 01:29:55PM -0500, Eric W. Biederman wrote: > Mark Brown writes: > > I fixed it up (see below) and can carry the fix as necessary. This > > is now fixed as far as linux-next is concerned, but any non trivial > > conflicts should be mentioned to your upstream maintainer

Re: linux-next: manual merge of the userns tree with the arm tree

Mark Brown writes: > Hi Eric, > > Yesterday's linux-next merge of the userns tree got a conflict in: > > arch/arm/mm/fault.c > > between commit: > > 8d9267cedb9e1d8edb8 ("ARM: spectre-v2: harden user aborts in kernel space") > > from the arm tree and commit: > >

Re: linux-next: manual merge of the userns tree with the arm tree

Mark Brown writes: > Hi Eric, > > Yesterday's linux-next merge of the userns tree got a conflict in: > > arch/arm/mm/fault.c > > between commit: > > 8d9267cedb9e1d8edb8 ("ARM: spectre-v2: harden user aborts in kernel space") > > from the arm tree and commit: > > 3eb0f5193b497083391

[PATCH] staging: mt7621-eth: Remove extra line in mtk_set_link_ksettings()

Fix extra line before end of function. Signed-off-by: Jefferson Capovilla --- drivers/staging/mt7621-eth/ethtool.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/mt7621-eth/ethtool.c b/drivers/staging/mt7621-eth/ethtool.c index b565d2a..e9f4092 100644 ---

[PATCH] staging: mt7621-eth: Remove extra line in mtk_set_link_ksettings()

Fix extra line before end of function. Signed-off-by: Jefferson Capovilla --- drivers/staging/mt7621-eth/ethtool.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/mt7621-eth/ethtool.c b/drivers/staging/mt7621-eth/ethtool.c index b565d2a..e9f4092 100644 ---

[PATCH] staging: mt7621-eth: fix line over 80 char in mtk_set_link_ksettings()

Fix 'line over 80 characters' issue found by checkpatch.pl script in mtk_set_link_ksettings(). Signed-off-by: Jefferson Capovilla --- drivers/staging/mt7621-eth/ethtool.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-eth/ethtool.c

[PATCH] staging: mt7621-eth: fix line over 80 char in mtk_set_link_ksettings()

Fix 'line over 80 characters' issue found by checkpatch.pl script in mtk_set_link_ksettings(). Signed-off-by: Jefferson Capovilla --- drivers/staging/mt7621-eth/ethtool.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-eth/ethtool.c

Re: Grant-

I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation:

Re: Grant-

I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation:

[PATCH v3] iio: 104-quad-8: Provide defines for magic numbers

This patch adds several register and bit defines to help improve the clarity of the code by cleaning up magic numbers throughout the driver. Signed-off-by: William Breathitt Gray --- Changes in v3: - Rename REG_CHANNEL_OPERATION to QUAD8_REG_CHAN_OP and

[PATCH v3] iio: 104-quad-8: Provide defines for magic numbers

This patch adds several register and bit defines to help improve the clarity of the code by cleaning up magic numbers throughout the driver. Signed-off-by: William Breathitt Gray --- Changes in v3: - Rename REG_CHANNEL_OPERATION to QUAD8_REG_CHAN_OP and REG_INDEX_INPUT_LEVELS to

[PATCH v2] iio: 104-quad-8: Provide defines for magic numbers

This patch adds several register and bit defines to help improve the clarity of the code by cleaning up magic numbers throughout the driver. Signed-off-by: William Breathitt Gray --- Changes in v2: - Add "QUAD8_" prefix to defines to help prevent future name

[PATCH v2] iio: 104-quad-8: Provide defines for magic numbers

This patch adds several register and bit defines to help improve the clarity of the code by cleaning up magic numbers throughout the driver. Signed-off-by: William Breathitt Gray --- Changes in v2: - Add "QUAD8_" prefix to defines to help prevent future name collisions

Re: [PATCH v3 14/14] tracing/selftest: Add test to test hist trigger between kernel event and trace_marker

On Fri, 25 May 2018 14:19:43 -0400 Steven Rostedt wrote: > On Fri, 25 May 2018 14:15:06 -0400 > Steven Rostedt wrote: > > > diff --git > > a/tools/testing/selftests/ftrace/test.d/trigger/trigger-trace-marker-synthetic-kernel.tc > > > >

Re: [PATCH v3 14/14] tracing/selftest: Add test to test hist trigger between kernel event and trace_marker

On Fri, 25 May 2018 14:19:43 -0400 Steven Rostedt wrote: > On Fri, 25 May 2018 14:15:06 -0400 > Steven Rostedt wrote: > > > diff --git > > a/tools/testing/selftests/ftrace/test.d/trigger/trigger-trace-marker-synthetic-kernel.tc > > > >

Re: [PATCH v3 13/14] tracing/selftest: Add selftests to test trace_marker histogram triggers

Hi Steve, On Fri, 25 May 2018 17:13:53 -0400 Steven Rostedt wrote: > On Fri, 25 May 2018 17:12:29 -0400 > Steven Rostedt wrote: > > > > #!/bin/sh > > Hmm, I think I need to make this #!/bin/bash > > > test_trace() { > > file=$1 > > x=$2 >

Re: [PATCH v3 13/14] tracing/selftest: Add selftests to test trace_marker histogram triggers

Hi Steve, On Fri, 25 May 2018 17:13:53 -0400 Steven Rostedt wrote: > On Fri, 25 May 2018 17:12:29 -0400 > Steven Rostedt wrote: > > > > #!/bin/sh > > Hmm, I think I need to make this #!/bin/bash > > > test_trace() { > > file=$1 > > x=$2 > > > > cat $file | while read line; do

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

On Sun, 27 May 2018 17:54:03 +0200 Miquel Raynal wrote: > Hi Boris, > > On Sun, 27 May 2018 17:13:37 +0200, Boris Brezillon > wrote: > > > On Sun, 27 May 2018 16:18:32 +0200 > > Miquel Raynal wrote: > > > >

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

On Sun, 27 May 2018 17:54:03 +0200 Miquel Raynal wrote: > Hi Boris, > > On Sun, 27 May 2018 17:13:37 +0200, Boris Brezillon > wrote: > > > On Sun, 27 May 2018 16:18:32 +0200 > > Miquel Raynal wrote: > > > > > Hi Stefan, > > > > > > On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner > > >

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

Hi Boris, On Sun, 27 May 2018 17:13:37 +0200, Boris Brezillon wrote: > On Sun, 27 May 2018 16:18:32 +0200 > Miquel Raynal wrote: > > > Hi Stefan, > > > > On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner > > wrote: > >

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

Hi Boris, On Sun, 27 May 2018 17:13:37 +0200, Boris Brezillon wrote: > On Sun, 27 May 2018 16:18:32 +0200 > Miquel Raynal wrote: > > > Hi Stefan, > > > > On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner > > wrote: > > > > > On 24.05.2018 13:53, Boris Brezillon wrote: > > > > Hi

[RFC PATCH 05/16] x86/split_lock: Use non atomic set and clear bit instructions in clear_cpufeature()

x86_capability can span two cache lines depending on kernel configuration and building environment. When #AC exception is enabled for split locked accesses, clear_cpufeature() may generate #AC exception because of atomic setting or clearing bits in x86_capability. But kernel clears cpufeature

[RFC PATCH 05/16] x86/split_lock: Use non atomic set and clear bit instructions in clear_cpufeature()

x86_capability can span two cache lines depending on kernel configuration and building environment. When #AC exception is enabled for split locked accesses, clear_cpufeature() may generate #AC exception because of atomic setting or clearing bits in x86_capability. But kernel clears cpufeature

[RFC PATCH 00/16] x86/split_lock: Enable #AC exception for split locked accesses

==Introduction== A split lock is any atomic operation whose operand crosses two cache lines. Since the operand spans two cache lines and the operation must be atomic, the system locks the bus while the CPU accesses the two cache lines. During bus locking, request from other CPUs or bus agents

[RFC PATCH 09/16] x86/split_lock: Add CONFIG to control #AC for split lock at boot time

User wants to specify how to set up #AC for split lock at boot time. CONFIG_SPLIT_LOCK_AC_ENABLE_DEFAULT is added to control split lock setting at boot time. Default value is 2: Don't explicitly enable or disable #AC for split lock. Inherit setting of #AC for split lock from firmware. Value 0

[RFC PATCH 04/16] x86/split_lock: Use non locked bit set instruction in set_cpu_cap

set_bit() called by set_cpu_cap() is a locked bit set instruction for atomic operation. Since the c->x86_capability can span two cache lines depending on kernel configuration and building evnironment, the locked bit set instruction may cause #AC exception when #AC exception for split lock is

[RFC PATCH 00/16] x86/split_lock: Enable #AC exception for split locked accesses

==Introduction== A split lock is any atomic operation whose operand crosses two cache lines. Since the operand spans two cache lines and the operation must be atomic, the system locks the bus while the CPU accesses the two cache lines. During bus locking, request from other CPUs or bus agents

[RFC PATCH 09/16] x86/split_lock: Add CONFIG to control #AC for split lock at boot time

User wants to specify how to set up #AC for split lock at boot time. CONFIG_SPLIT_LOCK_AC_ENABLE_DEFAULT is added to control split lock setting at boot time. Default value is 2: Don't explicitly enable or disable #AC for split lock. Inherit setting of #AC for split lock from firmware. Value 0

[RFC PATCH 04/16] x86/split_lock: Use non locked bit set instruction in set_cpu_cap

set_bit() called by set_cpu_cap() is a locked bit set instruction for atomic operation. Since the c->x86_capability can span two cache lines depending on kernel configuration and building evnironment, the locked bit set instruction may cause #AC exception when #AC exception for split lock is

[RFC PATCH 11/16] x86/split_lock: Add CONFIG to control #AC for split lock from kernel at boot time

By default, faulting kernel instruction that generates #AC due to split locked access is re-executed and doesn't block system. But in cases when user doesn't tolerate any split lock (e.g. in hard real time system), CONFIG_SPLIT_LOCK_AC_PANIC_ON_KERNEL is added to opt-in panic when #AC for split

[RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode

When #AC exception for split lock is triggered from a kernel instruction, by default we don't want the exception to panic the whole system. Instead, the exception handler should log the fault information for debug and continue the instruction execution. CPU generates #AC exception if split lock

[RFC PATCH 08/16] x86/split_lock: Set split lock during EFI runtime service

If kernel enables #AC for split locked accesses, EFI runtime service may hit #AC exception, treat it as fatal fault, and cause system hang. To avoid debugging potential buggy EFI runtime service code in firmware, restore to firmware split lock setting before entering EFI runtime service and

[RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split lock in kernel mode

When #AC exception for split lock is triggered from a kernel instruction, by default we don't want the exception to panic the whole system. Instead, the exception handler should log the fault information for debug and continue the instruction execution. CPU generates #AC exception if split lock

[RFC PATCH 08/16] x86/split_lock: Set split lock during EFI runtime service

If kernel enables #AC for split locked accesses, EFI runtime service may hit #AC exception, treat it as fatal fault, and cause system hang. To avoid debugging potential buggy EFI runtime service code in firmware, restore to firmware split lock setting before entering EFI runtime service and

[RFC PATCH 11/16] x86/split_lock: Add CONFIG to control #AC for split lock from kernel at boot time

By default, faulting kernel instruction that generates #AC due to split locked access is re-executed and doesn't block system. But in cases when user doesn't tolerate any split lock (e.g. in hard real time system), CONFIG_SPLIT_LOCK_AC_PANIC_ON_KERNEL is added to opt-in panic when #AC for split

[RFC PATCH 10/16] x86/split_lock: Add a debugfs interface to allow user to enable or disable #AC for split lock during run time

User wants to enable or disable #AC for split lock during run time. The interface /sys/kernel/debug/x86/split_lock/enable is added to allow user to control #AC for split lock and show current split lock status during run time. Writing 1 to the file enables #AC for split lock and writing 0

[RFC PATCH 14/16] x86/split_lock: Add debugfs interface to show and control firmware setting for split lock

By default, the firmware setting for split lock inherits from firmware setting before kernel boots. In cases like hard real time, user wants to identify split lock issues in firmware even when #AC for split lock is not enabled in firmware before kernel boots. The user may explicitly enable #AC

[RFC PATCH 10/16] x86/split_lock: Add a debugfs interface to allow user to enable or disable #AC for split lock during run time

User wants to enable or disable #AC for split lock during run time. The interface /sys/kernel/debug/x86/split_lock/enable is added to allow user to control #AC for split lock and show current split lock status during run time. Writing 1 to the file enables #AC for split lock and writing 0

[RFC PATCH 14/16] x86/split_lock: Add debugfs interface to show and control firmware setting for split lock

By default, the firmware setting for split lock inherits from firmware setting before kernel boots. In cases like hard real time, user wants to identify split lock issues in firmware even when #AC for split lock is not enabled in firmware before kernel boots. The user may explicitly enable #AC

[RFC PATCH 15/16] x86/split_lock: Add CONFIG and debugfs interface for testing #AC for split lock in kernel mode

Sometimes user wants to test how split lock in kernel mode is process. debugfs interface /sys/kernel/debug/x86/split_lock/test_kernel is provided to do the test. The interface is enabled by CONFIG_SPLIT_LOCK_AC_TEST. Writing 1 to the interface file triggers a split locked access in kernel and

[RFC PATCH 13/16] x86/split_lock: Add debugfs interface to control user mode behavior

Sometimes user wants to change how to handle user mode split lock during run time. Add interface /sys/kernel/debug/x86/split_lock/user_mode to allow user to choose to either generate SIGBUS (default) when hitting split lock in user or re-execute the user faulting instruction without generating

[RFC PATCH 15/16] x86/split_lock: Add CONFIG and debugfs interface for testing #AC for split lock in kernel mode

Sometimes user wants to test how split lock in kernel mode is process. debugfs interface /sys/kernel/debug/x86/split_lock/test_kernel is provided to do the test. The interface is enabled by CONFIG_SPLIT_LOCK_AC_TEST. Writing 1 to the interface file triggers a split locked access in kernel and

[RFC PATCH 13/16] x86/split_lock: Add debugfs interface to control user mode behavior

Sometimes user wants to change how to handle user mode split lock during run time. Add interface /sys/kernel/debug/x86/split_lock/user_mode to allow user to choose to either generate SIGBUS (default) when hitting split lock in user or re-execute the user faulting instruction without generating

RE: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

> > Another follow on question is, does every firmware support both > > blocking and non-blocking variants (specially legacy EFI firmware)? I > > am worried about this because, presently efi_delete_dummy_variable() > > uses set_variable() and > > query_variable_info() but if I change

[RFC PATCH 06/16] x86/split_lock: Save #AC setting for split lock in firmware in boot time and restore the setting in reboot

Firmware may contain split locked instructions. #AC handler in firmware may treat split lock as fatal fault and stop execution. If kernel enables #AC exception for split locked accesses and then kernel returns to firmware during reboot, the firmware reboot code may hit #AC exception and block the

[RFC PATCH 16/16] x86/split_lock: Add user space split lock test in selftest

User may use the selftest to test how user space split lock is handled, If #AC exception is enabled for split lock, the test generates split locked access from user space and tests how the split lock access is handled in two ways: 1. A SIGBUS is delivered to the test processor. This is specified

RE: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

> > Another follow on question is, does every firmware support both > > blocking and non-blocking variants (specially legacy EFI firmware)? I > > am worried about this because, presently efi_delete_dummy_variable() > > uses set_variable() and > > query_variable_info() but if I change

[RFC PATCH 06/16] x86/split_lock: Save #AC setting for split lock in firmware in boot time and restore the setting in reboot

Firmware may contain split locked instructions. #AC handler in firmware may treat split lock as fatal fault and stop execution. If kernel enables #AC exception for split locked accesses and then kernel returns to firmware during reboot, the firmware reboot code may hit #AC exception and block the

[RFC PATCH 16/16] x86/split_lock: Add user space split lock test in selftest

User may use the selftest to test how user space split lock is handled, If #AC exception is enabled for split lock, the test generates split locked access from user space and tests how the split lock access is handled in two ways: 1. A SIGBUS is delivered to the test processor. This is specified

[RFC PATCH 01/16] x86/split_lock: Add CONFIG and enumerate #AC exception for split locked access feature

#AC for split lock is supported on Tremont and future processors. We need to enumerate the feature on processors. Add CONFIG_SPLIT_LOCK_AC (default: y, dependent on X86 and CPU_SUP_INTEL) to control inclusion of the feature. Bit 29 in MSR TEST_CTL 0x33 can only be set on processors that support

[RFC PATCH 07/16] x86/split_lock: Handle suspend/hibernate and resume

During suspend or hibernation, system enters firmware. To avoid potential firmware issue that may generate #AC exception for split locked accesses, handle the #AC as fatal exception, and block suspend or hibernation, the setting of #AC for split lock is restored to firmware setting during suspend

[RFC PATCH 01/16] x86/split_lock: Add CONFIG and enumerate #AC exception for split locked access feature

#AC for split lock is supported on Tremont and future processors. We need to enumerate the feature on processors. Add CONFIG_SPLIT_LOCK_AC (default: y, dependent on X86 and CPU_SUP_INTEL) to control inclusion of the feature. Bit 29 in MSR TEST_CTL 0x33 can only be set on processors that support

[RFC PATCH 07/16] x86/split_lock: Handle suspend/hibernate and resume

During suspend or hibernation, system enters firmware. To avoid potential firmware issue that may generate #AC exception for split locked accesses, handle the #AC as fatal exception, and block suspend or hibernation, the setting of #AC for split lock is restored to firmware setting during suspend

[RFC PATCH 12/16] x86/split_lock: Add a debugfs interface to allow user to change how to handle split lock in kernel mode during run time

CONFIG_SPLIT_LOCK_AC_PANIC_ON_KERNEL defines how to handle split lock in kernel mode by default. But sometimes user wants to change the default behavior. The interface /sys/kernel/debug/x86/split_lock/kernel_mode is added to allow user to do so. For example, the interface shows "[re-execute]

[RFC PATCH 12/16] x86/split_lock: Add a debugfs interface to allow user to change how to handle split lock in kernel mode during run time

CONFIG_SPLIT_LOCK_AC_PANIC_ON_KERNEL defines how to handle split lock in kernel mode by default. But sometimes user wants to change the default behavior. The interface /sys/kernel/debug/x86/split_lock/kernel_mode is added to allow user to do so. For example, the interface shows "[re-execute]

[RFC PATCH 03/16] x86/split_lock: Set up #AC exception for split locked accesses on all CPUs

#AC for split lock is set up when each CPU is brought up. By default, kernel disables the feature bit 29 in TEST_CTL MSR on each CPU. Signed-off-by: Fenghua Yu --- arch/x86/include/asm/cpu.h | 3 +++ arch/x86/kernel/cpu/common.c | 2 ++

[RFC PATCH 03/16] x86/split_lock: Set up #AC exception for split locked accesses on all CPUs

#AC for split lock is set up when each CPU is brought up. By default, kernel disables the feature bit 29 in TEST_CTL MSR on each CPU. Signed-off-by: Fenghua Yu --- arch/x86/include/asm/cpu.h | 3 +++ arch/x86/kernel/cpu/common.c | 2 ++ arch/x86/kernel/cpu/test_ctl.c | 14 ++

Re: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver

On Sun, May 27, 2018 at 03:22:06PM +, Vadim Pasternak wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Sunday, May 27, 2018 6:14 PM > > To: Vadim Pasternak > > Cc: dvh...@infradead.org; andy.shevche...@gmail.com;

Re: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver

On Sun, May 27, 2018 at 03:22:06PM +, Vadim Pasternak wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Sunday, May 27, 2018 6:14 PM > > To: Vadim Pasternak > > Cc: dvh...@infradead.org; andy.shevche...@gmail.com; linux- > >

RE: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Sunday, May 27, 2018 6:14 PM > To: Vadim Pasternak > Cc: dvh...@infradead.org; andy.shevche...@gmail.com; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org;

RE: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Sunday, May 27, 2018 6:14 PM > To: Vadim Pasternak > Cc: dvh...@infradead.org; andy.shevche...@gmail.com; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us; > Michael

Re: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver

On Sun, May 27, 2018 at 04:47:43PM +, Vadim Pasternak wrote: > Introduce new Mellanox platform driver to allow access to Mellanox > programmable device register space trough sysfs interface. > The driver purpose is to provide sysfs interface for user space for the > registers essential for

Re: [PATCH v3 6/7] platform/mellanox: Introduce support for Mellanox register access driver

On Sun, May 27, 2018 at 04:47:43PM +, Vadim Pasternak wrote: > Introduce new Mellanox platform driver to allow access to Mellanox > programmable device register space trough sysfs interface. > The driver purpose is to provide sysfs interface for user space for the > registers essential for

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

On Sun, 27 May 2018 16:18:32 +0200 Miquel Raynal wrote: > Hi Stefan, > > On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner > wrote: > > > On 24.05.2018 13:53, Boris Brezillon wrote: > > > Hi Benjamin, > > > > > > On Thu, 24 May 2018 13:30:14 +0200

Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver

On Sun, 27 May 2018 16:18:32 +0200 Miquel Raynal wrote: > Hi Stefan, > > On Thu, 24 May 2018 14:19:18 +0200, Stefan Agner > wrote: > > > On 24.05.2018 13:53, Boris Brezillon wrote: > > > Hi Benjamin, > > > > > > On Thu, 24 May 2018 13:30:14 +0200 > > > Benjamin Lindqvist wrote: > > >

[PATCH 3/5] doc: add Italian translation skeleton

Signed-off-by: Federico Vaga Signed-off-by: Alessia Mantegazza --- Documentation/index.rst| 8 ++ .../translations/it_IT/disclaimer-ita.rst | 11 +++ Documentation/translations/it_IT/index.rst |

[PATCH 4/5] doc:it_IT: add doc-guide translation

Signed-off-by: Federico Vaga Signed-off-by: Alessia Mantegazza --- .../translations/it_IT/doc-guide/hello.dot | 3 + .../translations/it_IT/doc-guide/index.rst | 24 ++ .../translations/it_IT/doc-guide/kernel-doc.rst| 402

[PATCH 3/5] doc: add Italian translation skeleton

Signed-off-by: Federico Vaga Signed-off-by: Alessia Mantegazza --- Documentation/index.rst| 8 ++ .../translations/it_IT/disclaimer-ita.rst | 11 +++ Documentation/translations/it_IT/index.rst | 101 + 3 files changed, 120

[PATCH 4/5] doc:it_IT: add doc-guide translation

Signed-off-by: Federico Vaga Signed-off-by: Alessia Mantegazza --- .../translations/it_IT/doc-guide/hello.dot | 3 + .../translations/it_IT/doc-guide/index.rst | 24 ++ .../translations/it_IT/doc-guide/kernel-doc.rst| 402 ++

Re: [PATCH V3 rdma-next 3/4] RDMA/uverbs: Hoist the common process of disassociate_ucontext into ib core

On Sat, May 26, 2018 at 04:41:46PM +0800, Wei Hu (Xavier) wrote: > This patch hoisted the common process of disassociate_ucontext > callback function into ib core code, and these code are common > to ervery ib_device driver. > > Signed-off-by: Wei Hu (Xavier) > --- >

Re: [PATCH V3 rdma-next 3/4] RDMA/uverbs: Hoist the common process of disassociate_ucontext into ib core

On Sat, May 26, 2018 at 04:41:46PM +0800, Wei Hu (Xavier) wrote: > This patch hoisted the common process of disassociate_ucontext > callback function into ib core code, and these code are common > to ervery ib_device driver. > > Signed-off-by: Wei Hu (Xavier) > --- >

[PATCH 1/5] doc: typos and minor fixes

Signed-off-by: Federico Vaga --- Documentation/doc-guide/kernel-doc.rst| 2 +- Documentation/doc-guide/parse-headers.rst | 4 ++-- Documentation/doc-guide/sphinx.rst| 4 ++-- Documentation/index.rst | 2 +-

[PATCH 2/5] doc: add chapter labels

The idea is to make it easier to create references (doc-guide does the same). Signed-off-by: Federico Vaga --- Documentation/index.rst| 2 ++ Documentation/kernel-hacking/index.rst | 2 ++ 2 files changed, 4 insertions(+) diff --git

doc: Italian translation

Ciao Jonathan, here the doc-guide translated in Italian. This set of patches includes some minor changes to the main one. The idea of this first set of patches is also to adjust the structure and our expectations. We tried to translate everything in **Italian**; which means that we avoided

[PATCH 1/5] doc: typos and minor fixes

Signed-off-by: Federico Vaga --- Documentation/doc-guide/kernel-doc.rst| 2 +- Documentation/doc-guide/parse-headers.rst | 4 ++-- Documentation/doc-guide/sphinx.rst| 4 ++-- Documentation/index.rst | 2 +- Documentation/sphinx/parse-headers.pl | 2 +- 5 files

[PATCH 2/5] doc: add chapter labels

The idea is to make it easier to create references (doc-guide does the same). Signed-off-by: Federico Vaga --- Documentation/index.rst| 2 ++ Documentation/kernel-hacking/index.rst | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Documentation/index.rst

doc: Italian translation

Ciao Jonathan, here the doc-guide translated in Italian. This set of patches includes some minor changes to the main one. The idea of this first set of patches is also to adjust the structure and our expectations. We tried to translate everything in **Italian**; which means that we avoided

[PATCH v3 7/7] platform/x86: mlx-platform: Add mlxreg-io platform driver activation

Add mlxreg-io platform driver activation. Access driver uses the same regmap infrastructure as others Mellanox platform drivers. Specific registers description for default platform data configuration are added to mlx-platform. There are the registers for resets control, reset causes monitoring,

[PATCH v3 7/7] platform/x86: mlx-platform: Add mlxreg-io platform driver activation

Add mlxreg-io platform driver activation. Access driver uses the same regmap infrastructure as others Mellanox platform drivers. Specific registers description for default platform data configuration are added to mlx-platform. There are the registers for resets control, reset causes monitoring,

<    1   2   3   4   >