[PATCH 2/2] x86/microcode: Do the family check first

ov Cc: # 4.11.. Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://bugzilla.suse.com/show_bug.cgi?id=1061396 Link: http://lkml.kernel.org/r/20171012112316.977-1...@alien8.de Signed-off-by: Ingo Molnar Cc: # 4.4.x Signed-off-by: Rolf Neugebauer --- arch/x86/kernel/cpu/m

[PATCH 1/2] x86/microcode/AMD: Do not load when running on a hypervisor

e Signed-off-by: Thomas Gleixner Cc: # 4.4.x Signed-off-by: Rolf Neugebauer --- arch/x86/kernel/cpu/microcode/core.c | 28 +++- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c ind

Re: x86/microcode/intel: Division by zero panic in 4.9.79 and 4.4.114

On Thu, Feb 8, 2018 at 2:53 PM, Borislav Petkov wrote: > On Thu, Feb 08, 2018 at 01:55:48PM +0000, Rolf Neugebauer wrote: >> On the 4.4 kernel, 1f161f67a272c ("x86/microcode: Do the family check >> first") does not apply cleanly. Looks like it relies on 309aac77768c0 >

Re: x86/microcode/intel: Division by zero panic in 4.9.79 and 4.4.114

On Wed, Feb 7, 2018 at 6:12 PM, Borislav Petkov wrote: > On Wed, Feb 07, 2018 at 04:31:59PM +0000, Rolf Neugebauer wrote: >> arch/x86/kernel/cpu/microcode/core.c | 28 +++- >> 1 file changed, 19 insertions(+), 9 deletions(-) >> >> diff

Re: x86/microcode/intel: Division by zero panic in 4.9.79 and 4.4.114

On Wed, Feb 7, 2018 at 2:34 PM, Greg KH wrote: > On Tue, Feb 06, 2018 at 03:24:44PM +0100, Borislav Petkov wrote: >> On Tue, Feb 06, 2018 at 02:09:35PM +0000, Rolf Neugebauer wrote: >> > The backport of 7e702d17ed1 ("x86/microcode/intel: Extend BDW >> > late-loa

x86/microcode/intel: Division by zero panic in 4.9.79 and 4.4.114

The backport of 7e702d17ed1 ("x86/microcode/intel: Extend BDW late-loading further with LLC size check") to 4.9.79 and 4.4.14 causes a division by zero panic on some single vCPU machine types on Google Cloud (e.g. g1-small and n1-standard-1): [1.591435] divide error: [#1] SMP [1.59196

Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving

> receiving path. > > Cc: Rolf Neugebauer > Signed-off-by: Jason Wang Acked-by: Rolf Neugebauer Ah, I missed this use of the function. Looks like this patch does not regress the issue I was seeing with virtio_net. Rolf > --- > drivers/net/macvtap.c | 2 +- > dri

Re: Long delays creating a netns after deleting one (possibly RCU related)

On Thu, Nov 10, 2016 at 9:24 PM, Paul E. McKenney wrote: > On Thu, Nov 10, 2016 at 09:37:47AM -0800, Cong Wang wrote: >> (Cc'ing Paul) >> >> On Wed, Nov 9, 2016 at 7:42 AM, Rolf Neugebauer >> wrote: >> > Hi >> > >> > We notice