[PATCH 4.9 12/92] auxdisplay: img-ascii-lcd: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Jesse Chan commit 09c479f7f1fbfaf848e5813996793966cd50be81 upstream. This change resolves a new compile-time warning when built as a loadable module: WARNING: modpost: missing

[PATCH 4.9 12/92] auxdisplay: img-ascii-lcd: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Jesse Chan commit 09c479f7f1fbfaf848e5813996793966cd50be81 upstream. This change resolves a new compile-time warning when built as a loadable module: WARNING: modpost: missing

[PATCH] x86/spectre_v2: Remove 0xc2 from spectre_bad_microcodes

According to the latest microcode update from Intel (on Feb 8, 2018) on Skylake we should be using the microcode revisions 0xC2***, so we need to remove that from the blacklist now. Signed-off-by: Darren Kenny Reviewed-by: Konrad Rzeszutek Wilk

[PATCH 4.9 40/92] x86/cpufeatures: Add Intel feature bits for Speculation Control

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit fc67dd70adb711a45d2ef34e12d1a8be75edde61) Add three feature bits exposed by new microcode on Intel CPUs for speculation control.

[PATCH] x86/spectre_v2: Remove 0xc2 from spectre_bad_microcodes

According to the latest microcode update from Intel (on Feb 8, 2018) on Skylake we should be using the microcode revisions 0xC2***, so we need to remove that from the blacklist now. Signed-off-by: Darren Kenny Reviewed-by: Konrad Rzeszutek Wilk Tested-by: Konrad Rzeszutek Wilk ---

[PATCH 4.9 40/92] x86/cpufeatures: Add Intel feature bits for Speculation Control

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit fc67dd70adb711a45d2ef34e12d1a8be75edde61) Add three feature bits exposed by new microcode on Intel CPUs for speculation control. Signed-off-by:

[PATCH 4.9 41/92] x86/cpufeatures: Add AMD feature bits for Speculation Control

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 5d10cbc91d9eb5537998b65608441b592eec65e7) AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. See

[PATCH 4.9 41/92] x86/cpufeatures: Add AMD feature bits for Speculation Control

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 5d10cbc91d9eb5537998b65608441b592eec65e7) AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. See

Re: scripts/coccinelle/misc/shift.cocci: Refactoring?

> +| > +WARN_ON(x op@p y) > +| > +WARN_ON_ONCE(x op@p y) > +| Can it be nice to work with nested SmPL disjunctions so that a bit of duplicate SmPL code will be reduced? > +coccilib.org.print_todo(j0[0], msg) Will it be nicer to pass a string literal instead of a variable for the message as a

Re: scripts/coccinelle/misc/shift.cocci: Refactoring?

> +| > +WARN_ON(x op@p y) > +| > +WARN_ON_ONCE(x op@p y) > +| Can it be nice to work with nested SmPL disjunctions so that a bit of duplicate SmPL code will be reduced? > +coccilib.org.print_todo(j0[0], msg) Will it be nicer to pass a string literal instead of a variable for the message as a

[PATCH 4.9 45/92] x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 20ffa1caecca4db8f79fe665acdeaa5af815a24d) Expose indirect_branch_prediction_barrier() for use in subsequent patches. [ tglx: Add

[PATCH 4.9 42/92] x86/msr: Add definitions for new speculation control MSRs

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 1e340c60d0dd3ae07b5bedc16a0469c14b9f3410) Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's

[PATCH 4.9 45/92] x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 20ffa1caecca4db8f79fe665acdeaa5af815a24d) Expose indirect_branch_prediction_barrier() for use in subsequent patches. [ tglx: Add IBPB status to

[PATCH 4.9 42/92] x86/msr: Add definitions for new speculation control MSRs

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 1e340c60d0dd3ae07b5bedc16a0469c14b9f3410) Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's

[PATCHv3 5/5] x86/pconfig: Provide defines and helper to run MKTME_KEY_PROG leaf

MKTME_KEY_PROG allows to manipulate MKTME keys in the CPU. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/intel_pconfig.h | 50 1 file changed, 50 insertions(+) diff --git a/arch/x86/include/asm/intel_pconfig.h

[PATCHv3 5/5] x86/pconfig: Provide defines and helper to run MKTME_KEY_PROG leaf

MKTME_KEY_PROG allows to manipulate MKTME keys in the CPU. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/intel_pconfig.h | 50 1 file changed, 50 insertions(+) diff --git a/arch/x86/include/asm/intel_pconfig.h

Re: [PATCH V3 1/5] perf/x86/intel: fix event update for auto-reload

On Tue, Feb 06, 2018 at 12:58:23PM -0500, Liang, Kan wrote: > > > > With the exception of handling 'empty' buffers, I ended up with the > > below. Please try again. > > > > There are two small errors. After fixing them, the patch works well. Well, it still doesn't do A, two read()s without

Re: [PATCH V3 1/5] perf/x86/intel: fix event update for auto-reload

On Tue, Feb 06, 2018 at 12:58:23PM -0500, Liang, Kan wrote: > > > > With the exception of handling 'empty' buffers, I ended up with the > > below. Please try again. > > > > There are two small errors. After fixing them, the patch works well. Well, it still doesn't do A, two read()s without

[PATCHv3 3/5] x86/cpufeatures: Add Intel PCONFIG cpufeature

CPUID.0x7.0x0:EDX[18] indicates whether Intel CPU support PCONFIG instruction. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/cpufeatures.h

[PATCHv3 3/5] x86/cpufeatures: Add Intel PCONFIG cpufeature

CPUID.0x7.0x0:EDX[18] indicates whether Intel CPU support PCONFIG instruction. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index

[PATCHv3 1/5] x86/cpufeatures: Add Intel Total Memory Encryption cpufeature

CPUID.0x7.0x0:ECX[13] indicates whether CPU supports Intel Total Memory Encryption. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/cpufeatures.h

[PATCHv3 1/5] x86/cpufeatures: Add Intel Total Memory Encryption cpufeature

CPUID.0x7.0x0:ECX[13] indicates whether CPU supports Intel Total Memory Encryption. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index

[PATCHv3 2/5] x86/tme: Detect if TME and MKTME is activated by BIOS

IA32_TME_ACTIVATE MSR (0x982) can be used to check if BIOS has enabled TME and MKTME. It includes which encryption policy/algorithm is selected for TME or available for MKTME. For MKTME, the MSR also enumerates how many KeyIDs are available. We would need to exclude KeyID bits from physical

[PATCHv3 2/5] x86/tme: Detect if TME and MKTME is activated by BIOS

IA32_TME_ACTIVATE MSR (0x982) can be used to check if BIOS has enabled TME and MKTME. It includes which encryption policy/algorithm is selected for TME or available for MKTME. For MKTME, the MSR also enumerates how many KeyIDs are available. We would need to exclude KeyID bits from physical

[PATCHv3 4/5] x86/pconfig: Detect PCONFIG targets

Intel PCONFIG targets are enumerated via new CPUID leaf 0x1b. This patch detects all supported targets of PCONFIG and implements helper to check if the target is supported. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/intel_pconfig.h | 15 +++

[PATCHv3 4/5] x86/pconfig: Detect PCONFIG targets

Intel PCONFIG targets are enumerated via new CPUID leaf 0x1b. This patch detects all supported targets of PCONFIG and implements helper to check if the target is supported. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/intel_pconfig.h | 15 +++ arch/x86/kernel/cpu/Makefile

[PATCHv3 0/5] x86: Enumerate TME and PCONFIG, add MKTME_KEY_PROG helper

Multikey Total Memory Encryption (MKTME)[1] is a technology that allows transparent memory encryption in upcoming Intel platforms. MKTME is built on top of TME. TME allows encryption of the entirety of system memory using a single key. MKTME allows to have multiple encryption domains, each having

[PATCHv3 0/5] x86: Enumerate TME and PCONFIG, add MKTME_KEY_PROG helper

Multikey Total Memory Encryption (MKTME)[1] is a technology that allows transparent memory encryption in upcoming Intel platforms. MKTME is built on top of TME. TME allows encryption of the entirety of system memory using a single key. MKTME allows to have multiple encryption domains, each having

Re: Regression after commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly")

On Fri, Feb 09, 2018 at 05:12:56PM +0800, Kai Heng Feng wrote: > Hi Matthew, > > > On Feb 9, 2018, at 12:08 PM, Matthew Wilcox wrote: > > Alternatively, try this. It passes in GFP_DMA32 from vmalloc_32, > > regardless of whether ZONE_DMA32 exists or not. If ZONE_DMA32

Re: Regression after commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly")

On Fri, Feb 09, 2018 at 05:12:56PM +0800, Kai Heng Feng wrote: > Hi Matthew, > > > On Feb 9, 2018, at 12:08 PM, Matthew Wilcox wrote: > > Alternatively, try this. It passes in GFP_DMA32 from vmalloc_32, > > regardless of whether ZONE_DMA32 exists or not. If ZONE_DMA32 doesn't > > exist, then

[PATCH 4.9 14/92] ASoC: pcm512x: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Jesse Chan commit 0cab20cec0b663b7be8e2be5998d5a4113647f86 upstream. This change resolves a new compile-time warning when built as a loadable module: WARNING: modpost: missing

[PATCH 4.9 14/92] ASoC: pcm512x: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Jesse Chan commit 0cab20cec0b663b7be8e2be5998d5a4113647f86 upstream. This change resolves a new compile-time warning when built as a loadable module: WARNING: modpost: missing

[PATCH 4.9 16/92] x86/pti: Make unpoison of pgd for trusted boot work for real

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dave Hansen commit 445b69e3b75e42362a5bdc13c8b8f61599e2228a upstream The inital fix for trusted boot and PTI potentially misses the pgd clearing if pud_alloc()

[PATCH 4.9 16/92] x86/pti: Make unpoison of pgd for trusted boot work for real

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dave Hansen commit 445b69e3b75e42362a5bdc13c8b8f61599e2228a upstream The inital fix for trusted boot and PTI potentially misses the pgd clearing if pud_alloc() sets a PGD. It probably works

[PATCH 4.9 17/92] kaiser: allocate pgd with order 0 when pti=off

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Hugh Dickins The 4.9.77 version of "x86/pti/efi: broken conversion from efi to kernel page table" looked nicer than the 4.4.112 version, but was suboptimal on machines booted

[PATCH 4.9 17/92] kaiser: allocate pgd with order 0 when pti=off

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Hugh Dickins The 4.9.77 version of "x86/pti/efi: broken conversion from efi to kernel page table" looked nicer than the 4.4.112 version, but was suboptimal on machines booted with "pti=off" (or

[PATCH 4.9 09/92] powerpc/powernv: Check device-tree for RFI flush settings

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Oliver O'Halloran commit 6e032b350cd1fdb830f18f8320ef0e13b4e24094 upstream. New device-tree properties are available which tell the hypervisor settings related to the RFI

[PATCH 4.9 09/92] powerpc/powernv: Check device-tree for RFI flush settings

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Oliver O'Halloran commit 6e032b350cd1fdb830f18f8320ef0e13b4e24094 upstream. New device-tree properties are available which tell the hypervisor settings related to the RFI flush. Use them to

[PATCH 4.9 47/92] x86/nospec: Fix header guards names

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov (cherry picked from commit 7a32fc51ca938e67974cbb9db31e1a43f98345a9) ... to adhere to the _ASM_X86_ naming scheme. No functional change. Signed-off-by: Borislav

[PATCH 4.9 47/92] x86/nospec: Fix header guards names

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov (cherry picked from commit 7a32fc51ca938e67974cbb9db31e1a43f98345a9) ... to adhere to the _ASM_X86_ naming scheme. No functional change. Signed-off-by: Borislav Petkov

[PATCH 4.9 58/92] x86: Implement array_index_mask_nospec

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit babdde2698d482b6c0de1eab4f697cf5856c5859) array_index_nospec() uses a mask to sanitize user controllable array indexes, i.e.

[PATCH 4.9 58/92] x86: Implement array_index_mask_nospec

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit babdde2698d482b6c0de1eab4f697cf5856c5859) array_index_nospec() uses a mask to sanitize user controllable array indexes, i.e. generate a 0 mask if

[PATCH 4.9 57/92] array_index_nospec: Sanitize speculative array de-references

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit f3804203306e098dae9ca51540fcd5eb700d7f40) array_index_nospec() is proposed as a generic mechanism to mitigate against

[PATCH 4.9 57/92] array_index_nospec: Sanitize speculative array de-references

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit f3804203306e098dae9ca51540fcd5eb700d7f40) array_index_nospec() is proposed as a generic mechanism to mitigate against Spectre-variant-1 attacks, i.e.

[PATCH 4.9 56/92] Documentation: Document array_index_nospec

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Mark Rutland (cherry picked from commit f84a56f73dddaeac1dba8045b007f742f61cd2da) Document the rationale and usage of the new array_index_nospec() helper.

[PATCH 4.9 56/92] Documentation: Document array_index_nospec

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Mark Rutland (cherry picked from commit f84a56f73dddaeac1dba8045b007f742f61cd2da) Document the rationale and usage of the new array_index_nospec() helper. Signed-off-by: Mark Rutland

[PATCH 4.9 59/92] x86: Introduce barrier_nospec

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit b3d7ad85b80bbc404635dca80f5b129f6242bc7a) Rename the open coded form of this instruction sequence from rdtsc_ordered() into a

[PATCH 4.9 59/92] x86: Introduce barrier_nospec

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit b3d7ad85b80bbc404635dca80f5b129f6242bc7a) Rename the open coded form of this instruction sequence from rdtsc_ordered() into a generic barrier

[PATCH 4.9 61/92] x86/usercopy: Replace open coded stac/clac with __uaccess_{begin, end}

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit b5c4ae4f35325d520b230bab6eb3310613b72ac1) In preparation for converting some __uaccess_begin() instances to

[PATCH 4.9 61/92] x86/usercopy: Replace open coded stac/clac with __uaccess_{begin, end}

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit b5c4ae4f35325d520b230bab6eb3310613b72ac1) In preparation for converting some __uaccess_begin() instances to __uacess_begin_nospec(), make sure all

[PATCH 4.9 48/92] x86/bugs: Drop one "mitigation" from dmesg

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov (cherry picked from commit 55fa19d3e51f33d9cd4056d25836d93abf9438db) Make [0.031118] Spectre V2 mitigation: Mitigation: Full generic retpoline into [

[PATCH 4.9 48/92] x86/bugs: Drop one "mitigation" from dmesg

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov (cherry picked from commit 55fa19d3e51f33d9cd4056d25836d93abf9438db) Make [0.031118] Spectre V2 mitigation: Mitigation: Full generic retpoline into [0.031118]

[PATCH 4.9 68/92] x86/spectre: Fix spelling mistake: "vunerable"-> "vulnerable"

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Colin Ian King (cherry picked from commit e698dcdfcda41efd0984de539767b4cddd235f1e) Trivial fix to spelling mistake in pr_err error message text. Signed-off-by:

[PATCH 4.9 68/92] x86/spectre: Fix spelling mistake: "vunerable"-> "vulnerable"

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Colin Ian King (cherry picked from commit e698dcdfcda41efd0984de539767b4cddd235f1e) Trivial fix to spelling mistake in pr_err error message text. Signed-off-by: Colin Ian King

[PATCH 4.9 65/92] vfs, fdtable: Prevent bounds-check bypass via speculative execution

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit 56c30ba7b348b90484969054d561f711ba196507) 'fd' is a user controlled value that is used as a data dependency to read from the

[PATCH 4.9 65/92] vfs, fdtable: Prevent bounds-check bypass via speculative execution

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit 56c30ba7b348b90484969054d561f711ba196507) 'fd' is a user controlled value that is used as a data dependency to read from the 'fdt->fd' array. In order

[PATCH 4.9 69/92] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 7fcae1118f5fd44a862aa5c3525248e35ee67c3b) Despite the fact that all the other code there seems to be doing it, just using

[PATCH 4.9 69/92] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 7fcae1118f5fd44a862aa5c3525248e35ee67c3b) Despite the fact that all the other code there seems to be doing it, just using set_cpu_cap() in

[PATCH 4.9 71/92] x86/kvm: Update spectre-v1 mitigation

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit 085331dfc6bbe3501fb936e657331ca943827600) Commit 75f139aaf896 "KVM: x86: Add memory barrier on vmcs field lookup" added a raw

[PATCH 4.9 71/92] x86/kvm: Update spectre-v1 mitigation

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit 085331dfc6bbe3501fb936e657331ca943827600) Commit 75f139aaf896 "KVM: x86: Add memory barrier on vmcs field lookup" added a raw 'asm("lfence");' to

[PATCH 4.9 70/92] x86/paravirt: Remove noreplace-paravirt cmdline option

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Josh Poimboeuf (cherry picked from commit 12c69f1e94c89d40696e83804dd2f0965b5250cd) The 'noreplace-paravirt' option disables paravirt patching, leaving the original pv

[PATCH 4.9 70/92] x86/paravirt: Remove noreplace-paravirt cmdline option

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Josh Poimboeuf (cherry picked from commit 12c69f1e94c89d40696e83804dd2f0965b5250cd) The 'noreplace-paravirt' option disables paravirt patching, leaving the original pv indirect calls in

[PATCH 4.9 72/92] x86/retpoline: Avoid retpolines for built-in __init functions

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 66f793099a636862a71c59d4a6ba91387b155e0c) There's no point in building init code with retpolines, since it runs before any

[PATCH 4.9 72/92] x86/retpoline: Avoid retpolines for built-in __init functions

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 66f793099a636862a71c59d4a6ba91387b155e0c) There's no point in building init code with retpolines, since it runs before any potentially hostile

[PATCH 4.9 73/92] x86/spectre: Simplify spectre_v2 command line parsing

4.9-stable review patch. If anyone has any objections, please let me know. -- From: KarimAllah Ahmed (cherry picked from commit 9005c6834c0ffdfe46afa76656bd9276cca864f6) [dwmw2: Use ARRAY_SIZE] Signed-off-by: KarimAllah Ahmed

[PATCH 4.9 73/92] x86/spectre: Simplify spectre_v2 command line parsing

4.9-stable review patch. If anyone has any objections, please let me know. -- From: KarimAllah Ahmed (cherry picked from commit 9005c6834c0ffdfe46afa76656bd9276cca864f6) [dwmw2: Use ARRAY_SIZE] Signed-off-by: KarimAllah Ahmed Signed-off-by: David Woodhouse Signed-off-by:

[PATCH 4.9 74/92] x86/pti: Mark constant arrays as __initconst

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann (cherry picked from commit 4bf5d56d429cbc96c23d809a08f63cd29e1a702e) I'm seeing build failures from the two newly introduced arrays that are marked 'const' and

[PATCH 4.9 74/92] x86/pti: Mark constant arrays as __initconst

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann (cherry picked from commit 4bf5d56d429cbc96c23d809a08f63cd29e1a702e) I'm seeing build failures from the two newly introduced arrays that are marked 'const' and '__initdata',

Re: [Resend] Question: kselftests: bpf/test_maps failed

On 02/09/2018 06:14 AM, Li Zhijian wrote: > Hi > > INTEL 0-Day noticed that bpf/test_maps has different results at different > platforms. > when it fails, the details are like Sorry for the late reply and thanks for reporting! More below: > -- >   880 Failed to create hashmap

[PATCH 4.9 76/92] KVM: nVMX: kmap() cant fail

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Hildenbrand commit 42cf014d38d8822cce63703a467e00f65d000952 upstream. kmap() can't fail, therefore it will always return a valid pointer. Let's just get rid of the

Re: [Resend] Question: kselftests: bpf/test_maps failed

On 02/09/2018 06:14 AM, Li Zhijian wrote: > Hi > > INTEL 0-Day noticed that bpf/test_maps has different results at different > platforms. > when it fails, the details are like Sorry for the late reply and thanks for reporting! More below: > -- >   880 Failed to create hashmap

[PATCH 4.9 76/92] KVM: nVMX: kmap() cant fail

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Hildenbrand commit 42cf014d38d8822cce63703a467e00f65d000952 upstream. kmap() can't fail, therefore it will always return a valid pointer. Let's just get rid of the unnecessary checks.

[PATCH 4.9 81/92] KVM: VMX: make MSR bitmaps per-VCPU

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Paolo Bonzini (cherry picked from commit 904e14fb7cb96401a7dc803ca2863fd5ba32ffe6) Place the MSR bitmap in struct loaded_vmcs, and update it in place every time the

[PATCH 4.9 81/92] KVM: VMX: make MSR bitmaps per-VCPU

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Paolo Bonzini (cherry picked from commit 904e14fb7cb96401a7dc803ca2863fd5ba32ffe6) Place the MSR bitmap in struct loaded_vmcs, and update it in place every time the x2apic or APICv state can

[GIT PULL] fbdev fix for v4.16

Hi Linus, Please pull fbdev fix for v4.16 (just a single fix to make omapfb driver build again). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics The following changes since commit f1517df8701c9f12dae9ce7f43a5d300a6917619: Merge tag 'nfsd-4.16' of

[GIT PULL] fbdev fix for v4.16

Hi Linus, Please pull fbdev fix for v4.16 (just a single fix to make omapfb driver build again). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics The following changes since commit f1517df8701c9f12dae9ce7f43a5d300a6917619: Merge tag 'nfsd-4.16' of

Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

[...] >> > I'd like to know if any progress has been made on that problem (I may >> > have missed patches). >> > Had you had the time to look at the issue? >> >> I have looked at the issue, but not manage to cook some patches for it. >> >> However, it's on my top of my TODO list for mmc. No

Re: [PATCH 2/2] mmc: Add mmc_force_detect_change_begin / _end functions

[...] >> > I'd like to know if any progress has been made on that problem (I may >> > have missed patches). >> > Had you had the time to look at the issue? >> >> I have looked at the issue, but not manage to cook some patches for it. >> >> However, it's on my top of my TODO list for mmc. No

[PATCH 4.9 83/92] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

4.9-stable review patch. If anyone has any objections, please let me know. -- From: KarimAllah Ahmed (cherry picked from commit 28c1c9fabf48d6ad596273a11c46e0d0da3e14cd) Intel processors use MSR_IA32_ARCH_CAPABILITIES MSR to indicate RDCL_NO (bit 0) and

[PATCH 4.9 83/92] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

4.9-stable review patch. If anyone has any objections, please let me know. -- From: KarimAllah Ahmed (cherry picked from commit 28c1c9fabf48d6ad596273a11c46e0d0da3e14cd) Intel processors use MSR_IA32_ARCH_CAPABILITIES MSR to indicate RDCL_NO (bit 0) and IBRS_ALL (bit 1).

[PATCH 4.9 50/92] x86/cpufeatures: Clean up Spectre v2 related CPUID flags

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2) We want to expose the hardware features simply in /proc/cpuinfo as "ibrs", "ibpb" and

[PATCH 4.9 50/92] x86/cpufeatures: Clean up Spectre v2 related CPUID flags

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Woodhouse (cherry picked from commit 2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2) We want to expose the hardware features simply in /proc/cpuinfo as "ibrs", "ibpb" and "stibp". Since AMD

[PATCH 4.9 52/92] x86/spectre: Check CONFIG_RETPOLINE in command line parser

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dou Liyang (cherry picked from commit 9471eee9186a46893726e22ebb54cade3f9bc043) The spectre_v2 option 'auto' does not check whether CONFIG_RETPOLINE is enabled. As a

[PATCH 4.9 52/92] x86/spectre: Check CONFIG_RETPOLINE in command line parser

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dou Liyang (cherry picked from commit 9471eee9186a46893726e22ebb54cade3f9bc043) The spectre_v2 option 'auto' does not check whether CONFIG_RETPOLINE is enabled. As a consequence it fails to

[PATCH 4.9 46/92] x86/alternative: Print unadorned pointers

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov (cherry picked from commit 0e6c16c652cadaffd25a6bb326ec10da5bcec6b4) After commit ad67b74d2469 ("printk: hash addresses printed with %p") pointers are being

[PATCH 4.9 54/92] x86/entry/64: Push extra regs right away

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Andy Lutomirski (cherry picked from commit d1f7732009e0549eedf8ea1db948dc37be77fd46) With the fast path removed there is no point in splitting the push of the normal and the

[PATCH 4.9 46/92] x86/alternative: Print unadorned pointers

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov (cherry picked from commit 0e6c16c652cadaffd25a6bb326ec10da5bcec6b4) After commit ad67b74d2469 ("printk: hash addresses printed with %p") pointers are being hashed when

[PATCH 4.9 54/92] x86/entry/64: Push extra regs right away

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Andy Lutomirski (cherry picked from commit d1f7732009e0549eedf8ea1db948dc37be77fd46) With the fast path removed there is no point in splitting the push of the normal and the extra register

Re: [f2fs-dev] [PATCH] f2fs: add fi->commit_lock to protect commit GCed pages

The problem is that you can not find a proper value of the threshold time, when f2fs_gc select the GCed data page of the atomic file (which has atomic started but not atomic committed yet), then f2fs_gc will run into loop, and all the f2fs ops will be blocked in f2fs_balane_fs. If the threshold

Re: [f2fs-dev] [PATCH] f2fs: add fi->commit_lock to protect commit GCed pages

The problem is that you can not find a proper value of the threshold time, when f2fs_gc select the GCed data page of the atomic file (which has atomic started but not atomic committed yet), then f2fs_gc will run into loop, and all the f2fs ops will be blocked in f2fs_balane_fs. If the threshold

Re: [PATCH] base: power: domain: Replace mdelay with msleep

On 26 January 2018 at 09:38, Jia-Ju Bai wrote: > After checking all possible call chains to genpd_dev_pm_detach() and > genpd_dev_pm_attach() here, > my tool finds that these functions are never called in atomic context, > namely never in an interrupt handler or holding a

Re: [PATCH] base: power: domain: Replace mdelay with msleep

On 26 January 2018 at 09:38, Jia-Ju Bai wrote: > After checking all possible call chains to genpd_dev_pm_detach() and > genpd_dev_pm_attach() here, > my tool finds that these functions are never called in atomic context, > namely never in an interrupt handler or holding a spinlock. > Thus mdelay

[PATCH 4.9 88/92] ASoC: rsnd: dont call free_irq() on Parent SSI

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Kuninori Morimoto commit 1f8754d4daea5f257370a52a30fcb22798c54516 upstream. If SSI uses shared pin, some SSI will be used as parent SSI. Then, normal SSI's

[PATCH 4.9 88/92] ASoC: rsnd: dont call free_irq() on Parent SSI

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Kuninori Morimoto commit 1f8754d4daea5f257370a52a30fcb22798c54516 upstream. If SSI uses shared pin, some SSI will be used as parent SSI. Then, normal SSI's remove and Parent SSI's remove

[PATCH 4.9 91/92] drm: rcar-du: Fix race condition when disabling planes at CRTC stop

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Laurent Pinchart commit 641307df71fe77d7b38a477067495ede05d47295 upstream. When stopping the CRTC the driver must disable all planes and wait for the

[PATCH 4.9 91/92] drm: rcar-du: Fix race condition when disabling planes at CRTC stop

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Laurent Pinchart commit 641307df71fe77d7b38a477067495ede05d47295 upstream. When stopping the CRTC the driver must disable all planes and wait for the change to take effect at the next vblank.

[PATCH 4.9 85/92] KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL

4.9-stable review patch. If anyone has any objections, please let me know. -- From: KarimAllah Ahmed (cherry picked from commit b2ac58f90540e39324e7a29a7ad471407ae0bf48) [ Based on a patch from Paolo Bonzini ] ... basically doing

[PATCH 4.9 85/92] KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL

4.9-stable review patch. If anyone has any objections, please let me know. -- From: KarimAllah Ahmed (cherry picked from commit b2ac58f90540e39324e7a29a7ad471407ae0bf48) [ Based on a patch from Paolo Bonzini ] ... basically doing exactly what we do for VMX: - Passthrough

[PATCH 4.14 10/22] vhost_net: stop device during reset owner

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Jason Wang [ Upstream commit 4cd879515d686849eec5f718aeac62a70b067d82 ] We don't stop device before reset owner, this means we could try to serve any virtqueue kick

[PATCH 4.14 10/22] vhost_net: stop device during reset owner

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Jason Wang [ Upstream commit 4cd879515d686849eec5f718aeac62a70b067d82 ] We don't stop device before reset owner, this means we could try to serve any virtqueue kick before reset dev->worker.

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