Re: Linux 4.9.75

Hi Greg, sorry, I lost the overview -- the KPTI 4.14, 4.9 and 4.4 patch set is diverging... I am missing patches like x86/pti: Switch to kernel CR3 at early in entry_SYSCALL_compat() x86/pti: Make sure the user/kernel PTEs match in 4.9. The first one was really important but the problem

Re: Linux 4.9.75

Hi Greg, sorry, I lost the overview -- the KPTI 4.14, 4.9 and 4.4 patch set is diverging... I am missing patches like x86/pti: Switch to kernel CR3 at early in entry_SYSCALL_compat() x86/pti: Make sure the user/kernel PTEs match in 4.9. The first one was really important but the problem

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, Jan 04, 2018 at 08:08:55PM +, Woodhouse, David wrote: > On Thu, 2018-01-04 at 21:05 +0100, Greg KH wrote: > > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > > > > > > From: David Woodhouse > > > > > > We are impervious to the indirect branch

Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, Jan 04, 2018 at 08:08:55PM +, Woodhouse, David wrote: > On Thu, 2018-01-04 at 21:05 +0100, Greg KH wrote: > > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > > > > > > From: David Woodhouse > > > > > > We are impervious to the indirect branch prediction attack with > > >

[PATCH v1 3/3] x86/msr: Remove now unused definition of MFENCE_RDTSC feature

With the switch to using LFENCE_RDTSC on AMD platforms there is no longer a need for the MFENCE_RDTSC feature. Remove its usage and definition. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/cpufeatures.h |2 +- arch/x86/include/asm/msr.h |3 +--

[PATCH v1 3/3] x86/msr: Remove now unused definition of MFENCE_RDTSC feature

With the switch to using LFENCE_RDTSC on AMD platforms there is no longer a need for the MFENCE_RDTSC feature. Remove its usage and definition. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/cpufeatures.h |2 +- arch/x86/include/asm/msr.h |3 +-- 2 files changed, 2

[PATCH v1 2/3] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

With LFENCE now a serializing instruction, set the LFENCE_RDTSC feature since the LFENCE instruction has less overhead than the MFENCE instruction. Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH v1 1/3] x86/cpu/AMD: Make LFENCE a serializing instruction

To aid in speculation control, make LFENCE a serializing instruction. This is done by setting bit 1 of MSR 0xc0011029 (DE_CFG). Some families that support LFENCE do not have this MSR. For these families, the LFENCE instruction is already serializing. Signed-off-by: Tom Lendacky

[PATCH v1 2/3] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE_RDTSC

With LFENCE now a serializing instruction, set the LFENCE_RDTSC feature since the LFENCE instruction has less overhead than the MFENCE instruction. Signed-off-by: Tom Lendacky --- arch/x86/kernel/cpu/amd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v1 1/3] x86/cpu/AMD: Make LFENCE a serializing instruction

To aid in speculation control, make LFENCE a serializing instruction. This is done by setting bit 1 of MSR 0xc0011029 (DE_CFG). Some families that support LFENCE do not have this MSR. For these families, the LFENCE instruction is already serializing. Signed-off-by: Tom Lendacky ---

[PATCH v1 0/3] x86/cpu/AMD: Make LFENCE a serializing instruction on AMD

To aid in speculation control, the LFENCE instruction will be turned into a serializing instruction. There is less performance impact using LFENCE in this way compared to MFENCE. With LFENCE now being a serializing instruction, it can be used in rdtsc_ordered() in place of MFENCE_RDTSC. The

[PATCH v1 0/3] x86/cpu/AMD: Make LFENCE a serializing instruction on AMD

To aid in speculation control, the LFENCE instruction will be turned into a serializing instruction. There is less performance impact using LFENCE in this way compared to MFENCE. With LFENCE now being a serializing instruction, it can be used in rdtsc_ordered() in place of MFENCE_RDTSC. The

Re: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)

On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote: > On 01/03/2018 10:50 PM, Greg Kroah-Hartman wrote: > > On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote: > >> On 12/11/2017 09:59 AM, Catalin Marinas wrote: > >>> On Wed, Dec 06, 2017 at 12:35:19PM +, Will

Re: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)

On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote: > On 01/03/2018 10:50 PM, Greg Kroah-Hartman wrote: > > On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote: > >> On 12/11/2017 09:59 AM, Catalin Marinas wrote: > >>> On Wed, Dec 06, 2017 at 12:35:19PM +, Will

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

> Am 05.01.2018 um 15:30 schrieb Jani Nikula : > > On Thu, 04 Jan 2018, Knut Omang wrote: >> On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote: [...] >> Hmm - I have been burnt by the use of unstable interfaces in Python before, >> when I

Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

> Am 05.01.2018 um 15:30 schrieb Jani Nikula : > > On Thu, 04 Jan 2018, Knut Omang wrote: >> On Thu, 2018-01-04 at 17:50 +0200, Jani Nikula wrote: [...] >> Hmm - I have been burnt by the use of unstable interfaces in Python before, >> when I needed it to work on a (Linux) system with Python

Re: [PATCH 0/7] IBRS patch series

On Fri, Jan 05, 2018 at 03:38:24PM +, David Woodhouse wrote: > We had IBRS first, and especially on Broadwell and earlier, its > performance really is painful. > > Then came retpoline, purely as an optimisation. A very *important* > performance improvement, but an optimisation nonetheless. >

Re: [PATCH 0/7] IBRS patch series

On Fri, Jan 05, 2018 at 03:38:24PM +, David Woodhouse wrote: > We had IBRS first, and especially on Broadwell and earlier, its > performance really is painful. > > Then came retpoline, purely as an optimisation. A very *important* > performance improvement, but an optimisation nonetheless. >

Re: [PATCHv2] Device tree binding for Avago APDS990X light sensor

On Tue, Jan 02, 2018 at 01:44:51PM +0100, Pavel Machek wrote: > From: Filip Matijević > > This prepares binding for light sensor used in Nokia N9. "dt-bindings: ..." is the preferred subject prefix. > > Signed-off-by: Filip Matijević

Re: [PATCHv2] Device tree binding for Avago APDS990X light sensor

On Tue, Jan 02, 2018 at 01:44:51PM +0100, Pavel Machek wrote: > From: Filip Matijević > > This prepares binding for light sensor used in Nokia N9. "dt-bindings: ..." is the preferred subject prefix. > > Signed-off-by: Filip Matijević > Signed-off-by: Pavel Machek > > diff --git

Re: [PATCH v2 16/22] mmc: tmio: fix never-detected card insertion bug

Hi Wolfram, 2018-01-03 2:13 GMT+09:00 Wolfram Sang : > >> > The TMIO mmc cannot detect the card insertion in native_hotplug mode >> > if the driver is probed without a card inserted. >> >> Hmm, it works for me without your patch just fine. Iam currently >> researching it... >

Re: [PATCH v2 16/22] mmc: tmio: fix never-detected card insertion bug

Hi Wolfram, 2018-01-03 2:13 GMT+09:00 Wolfram Sang : > >> > The TMIO mmc cannot detect the card insertion in native_hotplug mode >> > if the driver is probed without a card inserted. >> >> Hmm, it works for me without your patch just fine. Iam currently >> researching it... > > It really doesn't

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 04:51:32PM +0100, Greg Kroah-Hartman wrote: > On Fri, Jan 05, 2018 at 10:32:49AM -0500, Pavel Tatashin wrote: (...) > > Reboots after about 30 seconds. > > > > Boots fine with nopti option. > > Crap. > > And 4.9.75 works for you just fine? Same with 4.15-rc6? > > I'm

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 04:51:32PM +0100, Greg Kroah-Hartman wrote: > On Fri, Jan 05, 2018 at 10:32:49AM -0500, Pavel Tatashin wrote: (...) > > Reboots after about 30 seconds. > > > > Boots fine with nopti option. > > Crap. > > And 4.9.75 works for you just fine? Same with 4.15-rc6? > > I'm

Re: [PATCH] net/mlx5e: hide an unused variable

From: Arnd Bergmann Date: Wed, 3 Jan 2018 23:40:11 +0100 > The uplink_rpriv variable was added at the start of the function but > only used inside of an #ifdef: > > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function > 'mlx5e_route_lookup_ipv6': >

Re: [PATCH] net/mlx5e: hide an unused variable

From: Arnd Bergmann Date: Wed, 3 Jan 2018 23:40:11 +0100 > The uplink_rpriv variable was added at the start of the function but > only used inside of an #ifdef: > > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function > 'mlx5e_route_lookup_ipv6': >

Re: Linux 4.4.110

On Fri, Jan 05, 2018 at 03:54:33PM +0100, Greg KH wrote: > I'm announcing the release of the 4.4.110 kernel. > > All users of the 4.4 kernel series must upgrade. > > But be careful, there have been some reports of problems with this > release during the -rc review cycle. Hopefully all of those

Re: Linux 4.4.110

On Fri, Jan 05, 2018 at 03:54:33PM +0100, Greg KH wrote: > I'm announcing the release of the 4.4.110 kernel. > > All users of the 4.4 kernel series must upgrade. > > But be careful, there have been some reports of problems with this > release during the -rc review cycle. Hopefully all of those

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 10:32:49AM -0500, Pavel Tatashin wrote: > Hi Greg, > > Just tested on my machine: > [0.00] Initializing cgroup subsys cpuset > > [0.00] Initializing cgroup subsys cpu > > [0.00] Initializing cgroup subsys cpuacct > > [0.00] Linux version

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 10:32:49AM -0500, Pavel Tatashin wrote: > Hi Greg, > > Just tested on my machine: > [0.00] Initializing cgroup subsys cpuset > > [0.00] Initializing cgroup subsys cpu > > [0.00] Initializing cgroup subsys cpuacct > > [0.00] Linux version

Re: [PATCH 10/12] clk: mediatek: switch to use dev_get_regmap() for MT7622 audsys

On Tue, Jan 02, 2018 at 07:47:52PM +0800, Ryder Lee wrote: > As the new audsys wrapper driver is in place, switch to use dev_get_regmap() > to obtain the regmap from its parent. > > This patch also add missing clock data 'CLK_AUDIO_AFE_CONN'. "also" is a keyword for this belonging in a separate

Re: [PATCH 10/12] clk: mediatek: switch to use dev_get_regmap() for MT7622 audsys

On Tue, Jan 02, 2018 at 07:47:52PM +0800, Ryder Lee wrote: > As the new audsys wrapper driver is in place, switch to use dev_get_regmap() > to obtain the regmap from its parent. > > This patch also add missing clock data 'CLK_AUDIO_AFE_CONN'. "also" is a keyword for this belonging in a separate

Re: [GIT PULL 00/25] LightNVM updates for 4.16

On Fri, Jan 05 2018, Matias Bjørling wrote: > Hi Jens, > > Here is a couple of patches for 4.16. > > This patchset prepares the lightnvm and pblk source code for the 2.0 > specification release. The specification is close to its final > revision. After these changes, 2.0 support is a quick drop.

Re: [GIT PULL 00/25] LightNVM updates for 4.16

On Fri, Jan 05 2018, Matias Bjørling wrote: > Hi Jens, > > Here is a couple of patches for 4.16. > > This patchset prepares the lightnvm and pblk source code for the 2.0 > specification release. The specification is close to its final > revision. After these changes, 2.0 support is a quick drop.

[PATCH][scsi-next] scsi: qla2xxx: remove redundant assignment of d

From: Colin Ian King The initialization of d is redundant as this value is never read and it is overwritten inside the subsequent for-loop. Remove this redundant assignment. Cleans up clang warning: drivers/scsi/qla2xxx/qla_gs.c:3985:29: warning: Value stored to 'd'

[PATCH][scsi-next] scsi: qla2xxx: remove redundant assignment of d

From: Colin Ian King The initialization of d is redundant as this value is never read and it is overwritten inside the subsequent for-loop. Remove this redundant assignment. Cleans up clang warning: drivers/scsi/qla2xxx/qla_gs.c:3985:29: warning: Value stored to 'd' during its initialization

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 04:25:33PM +0100, Thomas Voegtle wrote: > On Fri, 5 Jan 2018, Greg Kroah-Hartman wrote: > > > On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: > > > > > > When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a > > > segfault and the kernel

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, Jan 05, 2018 at 04:25:33PM +0100, Thomas Voegtle wrote: > On Fri, 5 Jan 2018, Greg Kroah-Hartman wrote: > > > On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: > > > > > > When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a > > > segfault and the kernel

Re: [PATCH 06/12] mfd: add DT bindings for MedaiTek audio subsystem

On Tue, Jan 02, 2018 at 07:47:31PM +0800, Ryder Lee wrote: > This patch adds documentation of the DT bindings for the MediaTek > audio subsystem wrapper. > > Signed-off-by: Ryder Lee > --- > .../devicetree/bindings/mfd/mtk-audsys.txt | 109 >

Re: [PATCH 06/12] mfd: add DT bindings for MedaiTek audio subsystem

On Tue, Jan 02, 2018 at 07:47:31PM +0800, Ryder Lee wrote: > This patch adds documentation of the DT bindings for the MediaTek > audio subsystem wrapper. > > Signed-off-by: Ryder Lee > --- > .../devicetree/bindings/mfd/mtk-audsys.txt | 109 > + > 1 file changed, 109

Re: [PATCH v3 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree

On Tue, Dec 19, 2017 at 09:07:42AM +0100, Philipp Rossak wrote: > This patch updates the sunxi-ir driver to set the base clock frequency from > devicetree. > > This is necessary since there are different ir receivers on the > market, that operate with different frequencies. So this value could be

Re: [PATCH v3 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree

On Tue, Dec 19, 2017 at 09:07:42AM +0100, Philipp Rossak wrote: > This patch updates the sunxi-ir driver to set the base clock frequency from > devicetree. > > This is necessary since there are different ir receivers on the > market, that operate with different frequencies. So this value could be

Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize interface

On 1/5/18 4:06 AM, Sagar Arun Kamble wrote: On 1/3/2018 1:23 AM, Pierre-Louis Bossart wrote: On 1/2/18 12:21 PM, Richard Cochran wrote: On Tue, Jan 02, 2018 at 11:15:45AM -0600, Pierre-Louis Bossart wrote: I wrote the code for HDaudio and I remember wasting time trying to figure out the

[PATCH] KVM: VMX: use same MSR bitmaps for 32-/64-bit modes, fix MSR bitmaps for processor tracing

KVM has a small optimization where it doesn't save/restore MSR_KERNEL_GS_BASE if the guest is in 32-bit mode. However, this complicates the code noticeably by doubling the number of possible MSR bitmaps. In addition, pt_disable_intercept_for_msr was only updating the "basic" MSR bitmap, because

Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize interface

On 1/5/18 4:06 AM, Sagar Arun Kamble wrote: On 1/3/2018 1:23 AM, Pierre-Louis Bossart wrote: On 1/2/18 12:21 PM, Richard Cochran wrote: On Tue, Jan 02, 2018 at 11:15:45AM -0600, Pierre-Louis Bossart wrote: I wrote the code for HDaudio and I remember wasting time trying to figure out the

[PATCH] KVM: VMX: use same MSR bitmaps for 32-/64-bit modes, fix MSR bitmaps for processor tracing

KVM has a small optimization where it doesn't save/restore MSR_KERNEL_GS_BASE if the guest is in 32-bit mode. However, this complicates the code noticeably by doubling the number of possible MSR bitmaps. In addition, pt_disable_intercept_for_msr was only updating the "basic" MSR bitmap, because

Re: [GIT PULL 24/25] lightnvm: pblk: add iostat support

On Fri, Jan 05 2018, Matias Bjørling wrote: > From: Javier González > > Since pblk registers its own block device, the iostat accounting is > not automatically done for us. Therefore, add the necessary > accounting logic to satisfy the iostat interface. Ignorant question -

Re: [GIT PULL 24/25] lightnvm: pblk: add iostat support

On Fri, Jan 05 2018, Matias Bjørling wrote: > From: Javier González > > Since pblk registers its own block device, the iostat accounting is > not automatically done for us. Therefore, add the necessary > accounting logic to satisfy the iostat interface. Ignorant question - why is it a raw block

Re: [PATCH 04/12] pci-p2p: Clear ACS P2P flags for all client devices

On Fri, 5 Jan 2018 01:47:01 -0500 Jerome Glisse wrote: > On Thu, Jan 04, 2018 at 08:33:00PM -0700, Alex Williamson wrote: > > On Thu, 4 Jan 2018 17:00:47 -0700 > > Logan Gunthorpe wrote: > > > > > On 04/01/18 03:35 PM, Alex Williamson wrote: > > > >

Re: [PATCH 04/12] pci-p2p: Clear ACS P2P flags for all client devices

On Fri, 5 Jan 2018 01:47:01 -0500 Jerome Glisse wrote: > On Thu, Jan 04, 2018 at 08:33:00PM -0700, Alex Williamson wrote: > > On Thu, 4 Jan 2018 17:00:47 -0700 > > Logan Gunthorpe wrote: > > > > > On 04/01/18 03:35 PM, Alex Williamson wrote: > > > > Yep, flipping these ACS bits invalidates

Re: [PATCH] dt-bindings: h8300 clocksource: correct spelling of pulse

On Tue, Jan 02, 2018 at 10:56:32AM +0100, Simon Horman wrote: > Correct what appears to be a typo in the spelling of pulse. > > Signed-off-by: Simon Horman > --- > Documentation/devicetree/bindings/timer/renesas,tpu.txt | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH] dt-bindings: h8300 clocksource: correct spelling of pulse

On Tue, Jan 02, 2018 at 10:56:32AM +0100, Simon Horman wrote: > Correct what appears to be a typo in the spelling of pulse. > > Signed-off-by: Simon Horman > --- > Documentation/devicetree/bindings/timer/renesas,tpu.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied. Rob

Re: [PATCH 0/7] IBRS patch series

On Fri, 2018-01-05 at 14:42 +, Van De Ven, Arjan wrote: > This is why I said I would like to see retpoline be the default, with > IBRS an opt-in for the paranoid. I guess David will turn that on ;-) I can live with that. It really depends how you look at it. We had IBRS first, and

Re: [PATCH 0/7] IBRS patch series

On Fri, 2018-01-05 at 14:42 +, Van De Ven, Arjan wrote: > This is why I said I would like to see retpoline be the default, with > IBRS an opt-in for the paranoid. I guess David will turn that on ;-) I can live with that. It really depends how you look at it. We had IBRS first, and

Re: [PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

> @@ -429,10 +429,7 @@ static void __nvme_submit_cmd(struct nvme_queue *nvmeq, > { > u16 tail = nvmeq->sq_tail; > > - if (nvmeq->sq_cmds_io) > - memcpy_toio(>sq_cmds_io[tail], cmd, sizeof(*cmd)); > - else > - memcpy(>sq_cmds[tail], cmd, sizeof(*cmd)); > +

Re: [PATCH 09/12] nvme-pci: Use PCI p2pmem subsystem to manage the CMB

> @@ -429,10 +429,7 @@ static void __nvme_submit_cmd(struct nvme_queue *nvmeq, > { > u16 tail = nvmeq->sq_tail; > > - if (nvmeq->sq_cmds_io) > - memcpy_toio(>sq_cmds_io[tail], cmd, sizeof(*cmd)); > - else > - memcpy(>sq_cmds[tail], cmd, sizeof(*cmd)); > +

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Hi Greg, Just tested on my machine: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.4.110_pt_linux-v4.4.110 (ptatashi@ca-ostest441) (gcc version 4.8.5 20150623

Re: [PATCH 4.4 00/37] 4.4.110-stable review

Hi Greg, Just tested on my machine: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.4.110_pt_linux-v4.4.110 (ptatashi@ca-ostest441) (gcc version 4.8.5 20150623

Re: [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox

On Thu, Jan 04, 2018 at 03:51:31PM -0800, Wendy Liang wrote: > Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block > in ZynqMP SoC used for the communication between various processor > systems. > > Signed-off-by: Wendy Liang > --- >

Re: [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox

On Thu, Jan 04, 2018 at 03:51:31PM -0800, Wendy Liang wrote: > Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block > in ZynqMP SoC used for the communication between various processor > systems. > > Signed-off-by: Wendy Liang > --- > .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt

[PATCH][scsi-next] scsi: aacraid: remove redundant setting of variable c

From: Colin Ian King A previous commit no longer stores the contents of c, so we now have a situation where c is being updated but the value is never read. Clean up the code by removing the now redundant setting of variable c. Cleans up clang warning:

[PATCH][scsi-next] scsi: aacraid: remove redundant setting of variable c

From: Colin Ian King A previous commit no longer stores the contents of c, so we now have a situation where c is being updated but the value is never read. Clean up the code by removing the now redundant setting of variable c. Cleans up clang warning: drivers/scsi/aacraid/aachba.c:943:3:

Re: [PATCH 7/7] x86/microcode: Recheck IBRS features on microcode reload

Hello everyone, On Fri, Jan 05, 2018 at 02:32:17PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 04, 2018 at 07:50:33PM +0100, Borislav Petkov wrote: > > On Thu, Jan 04, 2018 at 07:34:30PM +0100, Andrea Arcangeli wrote: > > > void spec_ctrl_rescan_cpuid(void) > > > { > > > int cpu; > > > > >

Re: [PATCH 7/7] x86/microcode: Recheck IBRS features on microcode reload

Hello everyone, On Fri, Jan 05, 2018 at 02:32:17PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 04, 2018 at 07:50:33PM +0100, Borislav Petkov wrote: > > On Thu, Jan 04, 2018 at 07:34:30PM +0100, Andrea Arcangeli wrote: > > > void spec_ctrl_rescan_cpuid(void) > > > { > > > int cpu; > > > > >

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, 5 Jan 2018, Greg Kroah-Hartman wrote: On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system. The same kernel binary

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Fri, 5 Jan 2018, Greg Kroah-Hartman wrote: On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a segfault and the kernel panics (attempted to kill init). The VM host is a Haswell system. The same kernel binary

Re: [PATCH 8/8] net: tipc: remove unused hardirq.h

From: "Yang Shi" Date: Fri, 05 Jan 2018 06:46:48 +0800 > Any more comment on this change? These patches were not really submitted properly. If you post a series, the series goes to one destination and one tree. If they are supposed to go to multiple trees, submit them

Re: [PATCH 8/8] net: tipc: remove unused hardirq.h

From: "Yang Shi" Date: Fri, 05 Jan 2018 06:46:48 +0800 > Any more comment on this change? These patches were not really submitted properly. If you post a series, the series goes to one destination and one tree. If they are supposed to go to multiple trees, submit them individually rather than

Re: [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation

On 1/5/2018 5:14 AM, David Woodhouse wrote: > On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: >> cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature >> IA32_SPEC_CTRL (0x48) and IA32_PRED_CMD (0x49) >> IA32_SPEC_CTRL, bit0 – Indirect Branch Restricted Speculation (IBRS) >>

Re: [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation

On 1/5/2018 5:14 AM, David Woodhouse wrote: > On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote: >> cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature >> IA32_SPEC_CTRL (0x48) and IA32_PRED_CMD (0x49) >> IA32_SPEC_CTRL, bit0 – Indirect Branch Restricted Speculation (IBRS) >>

Re: [PATCH net] of_mdio: avoid MDIO bus removal when a PHY is missing

On Fri, Jan 05, 2018 at 11:36:14AM +0200, Madalin Bucur wrote: > If one of the child devices is missing the of_mdiobus_register_phy() > call will return -ENODEV. When a missing device is encountered the > registration of the remaining PHYs is stopped and the MDIO bus will > fail to register.

Re: [PATCH net] of_mdio: avoid MDIO bus removal when a PHY is missing

On Fri, Jan 05, 2018 at 11:36:14AM +0200, Madalin Bucur wrote: > If one of the child devices is missing the of_mdiobus_register_phy() > call will return -ENODEV. When a missing device is encountered the > registration of the remaining PHYs is stopped and the MDIO bus will > fail to register.

Re: [PATCH 0/7] IBRS patch series

On Fri, Jan 05, 2018 at 02:52:33PM +, Van De Ven, Arjan wrote: > I'm sorry but your whole statement reeks a little bit of "perfect is the > enemy of good" My point is exactly that this sentences could apply to spectre variant#2 in the first place.. If we start moving in any direction,

Re: [PATCH 0/7] IBRS patch series

On Fri, Jan 05, 2018 at 02:52:33PM +, Van De Ven, Arjan wrote: > I'm sorry but your whole statement reeks a little bit of "perfect is the > enemy of good" My point is exactly that this sentences could apply to spectre variant#2 in the first place.. If we start moving in any direction,

WARNING: CPU: 0 PID: 0 at ./include/linux/netfilter.h:233 arp_rcv

Hi, I am getting the following warning on a imx6ul-evk board running linux-next 20180105: [9.233290] [ cut here ] [9.242068] WARNING: CPU: 0 PID: 0 at ./include/linux/netfilter.h:233 arp_rcv+0x1f8/0x228 [9.250381] Modules linked in: [9.253633] CPU: 0 PID

WARNING: CPU: 0 PID: 0 at ./include/linux/netfilter.h:233 arp_rcv

Hi, I am getting the following warning on a imx6ul-evk board running linux-next 20180105: [9.233290] [ cut here ] [9.242068] WARNING: CPU: 0 PID: 0 at ./include/linux/netfilter.h:233 arp_rcv+0x1f8/0x228 [9.250381] Modules linked in: [9.253633] CPU: 0 PID

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 09:56:47AM -0800, Guenter Roeck wrote: > On Thu, Jan 04, 2018 at 06:16:04PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Jan 04, 2018 at 06:14:15PM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Jan 04, 2018 at 06:11:02PM +0100, Greg Kroah-Hartman wrote: > > > > On Thu, Jan

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 09:56:47AM -0800, Guenter Roeck wrote: > On Thu, Jan 04, 2018 at 06:16:04PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Jan 04, 2018 at 06:14:15PM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Jan 04, 2018 at 06:11:02PM +0100, Greg Kroah-Hartman wrote: > > > > On Thu, Jan

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 04:48:48PM -0500, Pavel Tatashin wrote: > [6.159992] Code: 89 83 78 06 01 00 b8 01 00 00 00 5b 41 5c 41 5d > 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 31 d2 48 8b 87 c8 00 00 > 00 48 89 e5 0f c1 50 0c 89 97 d0 00 00 00 83 e2 01 b8 01 00 00 00 > 74 1d > > Also,

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 04:48:48PM -0500, Pavel Tatashin wrote: > [6.159992] Code: 89 83 78 06 01 00 b8 01 00 00 00 5b 41 5c 41 5d > 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 31 d2 48 8b 87 c8 00 00 > 00 48 89 e5 0f c1 50 0c 89 97 d0 00 00 00 83 e2 01 b8 01 00 00 00 > 74 1d > > Also,

Re: Linux 4.14.12

diff --git a/Makefile b/Makefile index 655887067dc7..20f7d4de0f1c 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 14 -SUBLEVEL = 11 +SUBLEVEL = 12 EXTRAVERSION = NAME = Petit Gorille diff --git

Re: Linux 4.14.12

diff --git a/Makefile b/Makefile index 655887067dc7..20f7d4de0f1c 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 14 -SUBLEVEL = 11 +SUBLEVEL = 12 EXTRAVERSION = NAME = Petit Gorille diff --git

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 15:42), Petr Mladek wrote: [..] > > oh, one more thing. one extra patch, which gets rid of > > print_symbol()/__print_symbol(). > > I am all for it. But I would postpone this removal to 4.17. > The reason is rather ugly. 13th patch is already in arc tree. > We would need to shuffle

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 15:42), Petr Mladek wrote: [..] > > oh, one more thing. one extra patch, which gets rid of > > print_symbol()/__print_symbol(). > > I am all for it. But I would postpone this removal to 4.17. > The reason is rather ugly. 13th patch is already in arc tree. > We would need to shuffle

Re: [PATCH v3 0/6] arm: sunxi: IR support for A83T

Hi, On Fri, Jan 05, 2018 at 12:02:53PM +, Sean Young wrote: > On Tue, Dec 19, 2017 at 09:07:41AM +0100, Philipp Rossak wrote: > > This patch series adds support for the sunxi A83T ir module and enhances > > the sunxi-ir driver. Right now the base clock frequency for the ir driver > > is a

Re: [PATCH v3 0/6] arm: sunxi: IR support for A83T

Hi, On Fri, Jan 05, 2018 at 12:02:53PM +, Sean Young wrote: > On Tue, Dec 19, 2017 at 09:07:41AM +0100, Philipp Rossak wrote: > > This patch series adds support for the sunxi A83T ir module and enhances > > the sunxi-ir driver. Right now the base clock frequency for the ir driver > > is a

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: > > When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a > segfault and the kernel panics (attempted to kill init). > The VM host is a Haswell system. > > The same kernel binary boots fine on a (other) Haswell system.

Re: [PATCH 4.4 00/37] 4.4.110-stable review

On Thu, Jan 04, 2018 at 08:38:23PM +0100, Thomas Voegtle wrote: > > When I start 4.4.110-rc1 on a virtual machine (qemu) init throws a > segfault and the kernel panics (attempted to kill init). > The VM host is a Haswell system. > > The same kernel binary boots fine on a (other) Haswell system.

[RFCv2 4/4] bpf: inhibit speculated out-of-bounds pointers

Note: this patch is an *example* use of the nospec API. It is understood that this is incomplete, etc. Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building

[RFCv2 4/4] bpf: inhibit speculated out-of-bounds pointers

Note: this patch is an *example* use of the nospec API. It is understood that this is incomplete, etc. Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building

[RFCv2 3/4] arm64: implement nospec_ptr()

This patch implements nospec_ptr() for arm64, following the recommended architectural sequence. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Cc: Dan Williams Cc: Peter Zijlstra ---

[RFCv2 3/4] arm64: implement nospec_ptr()

This patch implements nospec_ptr() for arm64, following the recommended architectural sequence. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Cc: Dan Williams Cc: Peter Zijlstra --- arch/arm64/include/asm/barrier.h | 55 1 file changed, 55

[RFCv2 2/4] Documentation: document nospec helpers

Document the rationale and usage of the new nospec*() helpers. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Cc: Dan Williams Cc: Jonathan Corbet Cc: Peter Zijlstra ---

[RFCv2 2/4] Documentation: document nospec helpers

Document the rationale and usage of the new nospec*() helpers. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Cc: Dan Williams Cc: Jonathan Corbet Cc: Peter Zijlstra --- Documentation/speculation.txt | 166 ++ 1 file changed, 166 insertions(+)

[RFCv2 1/4] asm-generic/barrier: add generic nospec helpers

Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building a side channel. This patch adds helpers which can be used to inhibit the use of out-of-bounds pointers

[RFCv2 0/4] API for inhibiting speculative arbitrary read primitives

Recently, Google Project Zero discovered several classes of attack against speculative execution. One of these, known as variant-1, allows explicit bounds checks to be bypassed under speculation, providing an arbitrary read gadget. Further details can be found on the GPZ blog [1] and the

[RFCv2 1/4] asm-generic/barrier: add generic nospec helpers

Under speculation, CPUs may mis-predict branches in bounds checks. Thus, memory accesses under a bounds check may be speculated even if the bounds check fails, providing a primitive for building a side channel. This patch adds helpers which can be used to inhibit the use of out-of-bounds pointers

[RFCv2 0/4] API for inhibiting speculative arbitrary read primitives

Recently, Google Project Zero discovered several classes of attack against speculative execution. One of these, known as variant-1, allows explicit bounds checks to be bypassed under speculation, providing an arbitrary read gadget. Further details can be found on the GPZ blog [1] and the

[PATCH] platform/x86: dell-smbios: Correct notation for filtering

The class/select were mistakingly put into octal notation but intended to be in decimal notation. Suggest-by: Pali Rohar Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-smbios.c | 8 1 file changed, 4 insertions(+), 4

Re: [PATCH v2 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs

On 05/01/18 14:46, James Morse wrote: > Hi Marc, Will, > > (SOB-chain suggests a missing From: tag on this and patch 7) > > On 05/01/18 13:12, Will Deacon wrote: >> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing >> and can theoretically be attacked by malicious code.

<    5   6   7   8   9   10   11   12   13   14   >