[PATCH 3.16 16/76] x86/alternatives: Fix optimize_nops() checking

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov commit 612e8e9350fd19cae6900cf36ea0c6892d1a0dca upstream. The alternatives code checks only the first byte whether it is a NOP, but with NOPs in front of the payload and

[PATCH 3.16 06/76] x86/cpu, x86/pti: Do not enable PTI on AMD processors

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Tom Lendacky commit 694d99d40972f12e59a3696effee8a376b79d7c8 upstream. AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against.

[PATCH 3.16 00/76] 3.16.56-rc1 review

This is the start of the stable review cycle for the 3.16.56 release. There are 76 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Mar 14 12:00:00 UTC 2018. Anything

[PATCH 3.16 00/76] 3.16.56-rc1 review

This is the start of the stable review cycle for the 3.16.56 release. There are 76 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Mar 14 12:00:00 UTC 2018. Anything

[PATCH 3.16 15/76] x86/alternatives: Make optimize_nops() interrupt safe and synced

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 66c117d7fa2ae429911e60d84bf31a90b2b96189 upstream. Richard reported the following crash: [0.036000] BUG: unable to handle kernel paging request

[PATCH 3.16 14/76] x86/alternatives: Fix ALTERNATIVE_2 padding generation properly

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov commit dbe4058a6a44af4ca5d146aebe01b0a1f9b7fd2a upstream. Quentin caught a corner case with the generation of instruction padding in the ALTERNATIVE_2 macro: if

[PATCH 3.16 15/76] x86/alternatives: Make optimize_nops() interrupt safe and synced

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 66c117d7fa2ae429911e60d84bf31a90b2b96189 upstream. Richard reported the following crash: [0.036000] BUG: unable to handle kernel paging request at 55501e06 [

[PATCH 3.16 14/76] x86/alternatives: Fix ALTERNATIVE_2 padding generation properly

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov commit dbe4058a6a44af4ca5d146aebe01b0a1f9b7fd2a upstream. Quentin caught a corner case with the generation of instruction padding in the ALTERNATIVE_2 macro: if len(orig_insn)

[PATCH 3.16 10/76] sysfs/cpu: Add vulnerability folder

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 87590ce6e373d1a5401f6539f0c59ef92dd924a9 upstream. As the meltdown/spectre problem affects several CPU architectures, it makes sense to have common

[PATCH 3.16 71/76] x86: reorganize SMAP handling in user space accesses

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Linus Torvalds commit 11f1a4b9755f5dbc3e822a96502ebe9b044b14d8 upstream. This reorganizes how we do the stac/clac instructions in the user access code. Instead

[PATCH 3.16 10/76] sysfs/cpu: Add vulnerability folder

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 87590ce6e373d1a5401f6539f0c59ef92dd924a9 upstream. As the meltdown/spectre problem affects several CPU architectures, it makes sense to have common way to express

[PATCH 3.16 71/76] x86: reorganize SMAP handling in user space accesses

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Linus Torvalds commit 11f1a4b9755f5dbc3e822a96502ebe9b044b14d8 upstream. This reorganizes how we do the stac/clac instructions in the user access code. Instead of adding the instructions

[PATCH 3.16 11/76] x86/cpu: Implement CPU vulnerabilites sysfs functions

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 61dc0f555b5c761cdafb0ba5bd41ecf22d68a4c4 upstream. Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and spectre_v2.

[PATCH 3.16 11/76] x86/cpu: Implement CPU vulnerabilites sysfs functions

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 61dc0f555b5c761cdafb0ba5bd41ecf22d68a4c4 upstream. Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and spectre_v2. Signed-off-by: Thomas

[PATCH 3.16 76/76] x86: fix build warnign with 32-bit PAE

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann I ran into a 4.9 build warning in randconfig testing, starting with the KAISER patches: arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':

[PATCH 3.2 101/104] x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd upstream. For __get_user() paths, do not allow the kernel to speculate on the value of a user controlled

[PATCH 3.2 101/104] x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd upstream. For __get_user() paths, do not allow the kernel to speculate on the value of a user controlled pointer. In addition to

[PATCH 3.16 76/76] x86: fix build warnign with 32-bit PAE

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann I ran into a 4.9 build warning in randconfig testing, starting with the KAISER patches: arch/x86/kernel/ldt.c: In function 'alloc_ldt_struct':

[PATCH 3.16 04/76] x86/cpufeatures: Make CPU bugs sticky

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 6cbd2171e89b13377261d15e64384df60ecb530e upstream. There is currently no way to force CPU bug bits like CPU feature bits. That makes it impossible

[PATCH 3.16 04/76] x86/cpufeatures: Make CPU bugs sticky

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 6cbd2171e89b13377261d15e64384df60ecb530e upstream. There is currently no way to force CPU bug bits like CPU feature bits. That makes it impossible to set a bug bit once

[PATCH 3.16 74/76] x86/usercopy: Replace open coded stac/clac with __uaccess_{begin, end}

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit b5c4ae4f35325d520b230bab6eb3310613b72ac1 upstream. In preparation for converting some __uaccess_begin() instances to __uacess_begin_nospec(),

[PATCH 3.16 74/76] x86/usercopy: Replace open coded stac/clac with __uaccess_{begin, end}

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit b5c4ae4f35325d520b230bab6eb3310613b72ac1 upstream. In preparation for converting some __uaccess_begin() instances to __uacess_begin_nospec(), make sure all 'from user'

[PATCH 3.16 68/76] nospec: Move array_index_nospec() parameter checking into separate macro

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Will Deacon commit 8fa80c503b484ddc1abbd10c7cb2ab81f3824a50 upstream. For architectures providing their own implementation of array_index_mask_nospec() in asm/barrier.h,

[PATCH 3.16 62/76] x86/kvm: Update spectre-v1 mitigation

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit 085331dfc6bbe3501fb936e657331ca943827600 upstream. Commit 75f139aaf896 "KVM: x86: Add memory barrier on vmcs field lookup" added a raw

[PATCH 3.16 68/76] nospec: Move array_index_nospec() parameter checking into separate macro

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Will Deacon commit 8fa80c503b484ddc1abbd10c7cb2ab81f3824a50 upstream. For architectures providing their own implementation of array_index_mask_nospec() in asm/barrier.h, attempting to use

[PATCH 3.16 62/76] x86/kvm: Update spectre-v1 mitigation

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

[PATCH 3.16 61/76] x86/paravirt: Remove 'noreplace-paravirt' cmdline option

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Josh Poimboeuf commit 12c69f1e94c89d40696e83804dd2f0965b5250cd upstream. The 'noreplace-paravirt' option disables paravirt patching, leaving the original pv indirect

[PATCH 3.16 61/76] x86/paravirt: Remove 'noreplace-paravirt' cmdline option

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Josh Poimboeuf commit 12c69f1e94c89d40696e83804dd2f0965b5250cd upstream. The 'noreplace-paravirt' option disables paravirt patching, leaving the original pv indirect calls in place. That's

[PATCH 3.16 63/76] x86/retpoline: Avoid retpolines for built-in __init functions

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: David Woodhouse commit 66f793099a636862a71c59d4a6ba91387b155e0c upstream. There's no point in building init code with retpolines, since it runs before any potentially

[PATCH 3.16 63/76] x86/retpoline: Avoid retpolines for built-in __init functions

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: David Woodhouse commit 66f793099a636862a71c59d4a6ba91387b155e0c upstream. There's no point in building init code with retpolines, since it runs before any potentially hostile userspace does.

[PATCH 3.16 72/76] x86: fix SMAP in 32-bit environments

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Linus Torvalds commit de9e478b9d49f3a0214310d921450cf5bb4a21e6 upstream. In commit 11f1a4b9755f ("x86: reorganize SMAP handling in user space accesses") I

[PATCH 3.16 72/76] x86: fix SMAP in 32-bit environments

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Linus Torvalds commit de9e478b9d49f3a0214310d921450cf5bb4a21e6 upstream. In commit 11f1a4b9755f ("x86: reorganize SMAP handling in user space accesses") I changed how the stac/clac

[PATCH 3.16 51/76] Documentation: Document array_index_nospec

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

[PATCH 3.16 51/76] Documentation: Document array_index_nospec

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

[PATCH 3.16 49/76] x86/cpu/bugs: Make retpoline module warning conditional

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit e383095c7fe8d218e00ec0f83e4b95ed4e627b02 upstream. If sysfs is disabled and RETPOLINE not defined: arch/x86/kernel/cpu/bugs.c:97:13: warning:

[PATCH 3.16 49/76] x86/cpu/bugs: Make retpoline module warning conditional

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit e383095c7fe8d218e00ec0f83e4b95ed4e627b02 upstream. If sysfs is disabled and RETPOLINE not defined: arch/x86/kernel/cpu/bugs.c:97:13: warning: ‘spectre_v2_bad_module’

[PATCH 3.16 42/76] x86/cpu: Change type of x86_cache_size variable to unsigned int

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: "Gustavo A. R. Silva" commit 24dbc6000f4b9b0ef5a9daecb161f1907733765a upstream. Currently, x86_cache_size is of type int, which makes no sense as we will never have a

[PATCH 3.16 42/76] x86/cpu: Change type of x86_cache_size variable to unsigned int

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: "Gustavo A. R. Silva" commit 24dbc6000f4b9b0ef5a9daecb161f1907733765a upstream. Currently, x86_cache_size is of type int, which makes no sense as we will never have a valid cache size equal

[PATCH 3.16 44/76] KVM: x86: Make indirect calls in emulator speculation safe

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra commit 1a29b5b7f347a1a9230c1e0af5b37e3e571588ab upstream. Replace the indirect calls with CALL_NOSPEC. Signed-off-by: Peter Zijlstra (Intel)

[PATCH 3.16 47/76] x86/nospec: Fix header guards names

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov commit 7a32fc51ca938e67974cbb9db31e1a43f98345a9 upstream. ... to adhere to the _ASM_X86_ naming scheme. No functional change. Signed-off-by: Borislav Petkov

[PATCH 3.16 64/76] x86/spectre: Simplify spectre_v2 command line parsing

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: KarimAllah Ahmed commit 9005c6834c0ffdfe46afa76656bd9276cca864f6 upstream. [dwmw2: Use ARRAY_SIZE] Signed-off-by: KarimAllah Ahmed Signed-off-by:

[PATCH 3.16 47/76] x86/nospec: Fix header guards names

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov commit 7a32fc51ca938e67974cbb9db31e1a43f98345a9 upstream. ... to adhere to the _ASM_X86_ naming scheme. No functional change. Signed-off-by: Borislav Petkov Signed-off-by:

[PATCH 3.16 64/76] x86/spectre: Simplify spectre_v2 command line parsing

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: KarimAllah Ahmed commit 9005c6834c0ffdfe46afa76656bd9276cca864f6 upstream. [dwmw2: Use ARRAY_SIZE] Signed-off-by: KarimAllah Ahmed Signed-off-by: David Woodhouse Signed-off-by: Thomas

[PATCH 3.16 44/76] KVM: x86: Make indirect calls in emulator speculation safe

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra commit 1a29b5b7f347a1a9230c1e0af5b37e3e571588ab upstream. Replace the indirect calls with CALL_NOSPEC. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner

[PATCH 3.16 45/76] KVM: VMX: Make indirect call speculation safe

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra commit c940a3fb1e2e9b7d03228ab28f375fb5a47ff699 upstream. Replace indirect call with CALL_NOSPEC. Signed-off-by: Peter Zijlstra (Intel)

[PATCH 3.16 45/76] KVM: VMX: Make indirect call speculation safe

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra commit c940a3fb1e2e9b7d03228ab28f375fb5a47ff699 upstream. Replace indirect call with CALL_NOSPEC. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner

[PATCH 3.16 59/76] x86/spectre: Report get_user mitigation for spectre_v1

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit edfbae53dab8348fca778531be9f4855d2ca0360 upstream. Reflect the presence of get_user(), __get_user(), and 'syscall' protections in sysfs. The

[PATCH 3.16 59/76] x86/spectre: Report get_user mitigation for spectre_v1

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit edfbae53dab8348fca778531be9f4855d2ca0360 upstream. Reflect the presence of get_user(), __get_user(), and 'syscall' protections in sysfs. The expectation is that new and

[PATCH 3.16 46/76] module/retpoline: Warn about missing retpoline in module

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Andi Kleen commit caf7501a1b4ec964190f31f9c3f163de252273b8 upstream. There's a risk that a kernel which has full retpoline mitigations becomes vulnerable when a module

[PATCH 3.16 65/76] x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Darren Kenny commit af189c95a371b59f493dbe0f50c0a09724868881 upstream. Fixes: 117cc7a908c83 ("x86/retpoline: Fill return stack buffer on vmexit") Signed-off-by:

[PATCH 3.16 46/76] module/retpoline: Warn about missing retpoline in module

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Andi Kleen commit caf7501a1b4ec964190f31f9c3f163de252273b8 upstream. There's a risk that a kernel which has full retpoline mitigations becomes vulnerable when a module gets loaded that hasn't

[PATCH 3.16 65/76] x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Darren Kenny commit af189c95a371b59f493dbe0f50c0a09724868881 upstream. Fixes: 117cc7a908c83 ("x86/retpoline: Fill return stack buffer on vmexit") Signed-off-by: Darren Kenny Signed-off-by:

[PATCH 3.2 087/104] x86/syscall: Sanitize syscall table de-references under speculation

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings commit 2fbd7af5af8665d18bcefae3e9700be07e22b681 upstream. The upstream version of this, touching C code, was written by Dan Williams, with the following

[PATCH 3.16 66/76] x86/cpufeatures: Clean up Spectre v2 related CPUID flags

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: David Woodhouse commit 2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2 upstream. We want to expose the hardware features simply in /proc/cpuinfo as "ibrs", "ibpb" and "stibp".

[PATCH 3.2 087/104] x86/syscall: Sanitize syscall table de-references under speculation

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings commit 2fbd7af5af8665d18bcefae3e9700be07e22b681 upstream. The upstream version of this, touching C code, was written by Dan Williams, with the following description: > The

[PATCH 3.16 66/76] x86/cpufeatures: Clean up Spectre v2 related CPUID flags

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: David Woodhouse commit 2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2 upstream. We want to expose the hardware features simply in /proc/cpuinfo as "ibrs", "ibpb" and "stibp". Since AMD has separate

Re: [PATCH] scsi: eata: drop VLA in reorder()

Adding kernel newbies to CC because I pose a few noob questions :) Adding Linus to CC because I quoted him. On Sun, Mar 11, 2018 at 10:06:58PM +0100, Salvatore Mesoraca wrote: > n_ready will always be less than or equal to MAX_MAILBOXES. > So we avoid a VLA[1] and use fixed-length arrays instead.

[PATCH 3.16 12/76] sysfs/cpu: Fix typos in vulnerability documentation

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: David Woodhouse commit 9ecccfaa7cb5249bd31bdceb93fcf5bedb8a24d8 upstream. Fixes: 87590ce6e ("sysfs/cpu: Add vulnerability folder") Signed-off-by: David Woodhouse

[PATCH 3.16 13/76] x86/alternatives: Guard NOPs optimization

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov commit 69df353ff305805fc16082d0c5bfa6e20fa8b863 upstream. Take a look at the first instruction byte before optimizing the NOP - there might be something else

[PATCH 3.16 12/76] sysfs/cpu: Fix typos in vulnerability documentation

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: David Woodhouse commit 9ecccfaa7cb5249bd31bdceb93fcf5bedb8a24d8 upstream. Fixes: 87590ce6e ("sysfs/cpu: Add vulnerability folder") Signed-off-by: David Woodhouse Signed-off-by: Thomas

[PATCH 3.16 13/76] x86/alternatives: Guard NOPs optimization

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Borislav Petkov commit 69df353ff305805fc16082d0c5bfa6e20fa8b863 upstream. Take a look at the first instruction byte before optimizing the NOP - there might be something else there already,

Re: [PATCH] scsi: eata: drop VLA in reorder()

Adding kernel newbies to CC because I pose a few noob questions :) Adding Linus to CC because I quoted him. On Sun, Mar 11, 2018 at 10:06:58PM +0100, Salvatore Mesoraca wrote: > n_ready will always be less than or equal to MAX_MAILBOXES. > So we avoid a VLA[1] and use fixed-length arrays instead.

[PATCH 3.16 05/76] x86/cpufeatures: Add X86_BUG_CPU_INSECURE

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit a89f040fa34ec9cd682aed98b8f04e3c47d998bd upstream. Many x86 CPUs leak information to user space due to missing isolation of user space and kernel

[PATCH 3.16 05/76] x86/cpufeatures: Add X86_BUG_CPU_INSECURE

3.16.56-rc1 review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit a89f040fa34ec9cd682aed98b8f04e3c47d998bd upstream. Many x86 CPUs leak information to user space due to missing isolation of user space and kernel space page tables.

[PATCH 3.2 010/104] rtlwifi: initialize local array and set value.

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Yunlian Jiang commit ec71997eff2231098212a99934c0fb987a9e6b04 upstream. GCC 4.8 is spitting out uninitialized-variable warnings against

[PATCH 3.2 010/104] rtlwifi: initialize local array and set value.

3.2.101-rc1 review patch. If anyone has any objections, please let me know. -- From: Yunlian Jiang commit ec71997eff2231098212a99934c0fb987a9e6b04 upstream. GCC 4.8 is spitting out uninitialized-variable warnings against "drivers/net/wireless/rtlwifi/rtl8192de/dm.c".

Re: [PATCH v12 0/6] Address error and recovery for AER and DPC

On 3/11/2018 6:03 PM, Bjorn Helgaas wrote: > On Wed, Feb 28, 2018 at 10:34:11PM +0530, Oza Pawandeep wrote: > That difference has been there since the beginning of DPC, so it has > nothing to do with *this* series EXCEPT for the fact that it really > complicates the logic you're adding to

Re: [PATCH v12 0/6] Address error and recovery for AER and DPC

On 3/11/2018 6:03 PM, Bjorn Helgaas wrote: > On Wed, Feb 28, 2018 at 10:34:11PM +0530, Oza Pawandeep wrote: > That difference has been there since the beginning of DPC, so it has > nothing to do with *this* series EXCEPT for the fact that it really > complicates the logic you're adding to

[PATCH] macintosh/adb: Use C99 initializers for struct adb_driver instances

Hopefully this will make it easier for the next reader who needs to check these pointers. No change to object files. Cc: Benjamin Herrenschmidt Signed-off-by: Finn Thain --- drivers/macintosh/adb-iop.c| 14 +++---

[PATCH] macintosh/adb: Use C99 initializers for struct adb_driver instances

Hopefully this will make it easier for the next reader who needs to check these pointers. No change to object files. Cc: Benjamin Herrenschmidt Signed-off-by: Finn Thain --- drivers/macintosh/adb-iop.c| 14 +++--- drivers/macintosh/macio-adb.c | 15 +++

Possible memory leak in acpi_ut_create_internal_object_dbg() in 4.16-rcX

Running kernel 4.16-rcX, kmemleak complains about a leak of one object. This is linux-ubqc:~ # echo scan > /sys/kernel/debug/kmemleak linux-ubqc:~ # cat /sys/kernel/debug/kmemleak unreferenced object 0x8802263b2630 (size 72): comm "swapper/0", pid 1, jiffies 4294892345 (age 8143.468s) hex

Possible memory leak in acpi_ut_create_internal_object_dbg() in 4.16-rcX

Running kernel 4.16-rcX, kmemleak complains about a leak of one object. This is linux-ubqc:~ # echo scan > /sys/kernel/debug/kmemleak linux-ubqc:~ # cat /sys/kernel/debug/kmemleak unreferenced object 0x8802263b2630 (size 72): comm "swapper/0", pid 1, jiffies 4294892345 (age 8143.468s) hex

Re: [PATCH net-next 00/12] fix some bugs for HNS3 driver

From: Peng Li Date: Sat, 10 Mar 2018 11:29:21 +0800 > This patchset fixes some bugs for HNS3 driver: > [Patch 1/12 - Patch 8/12] fix various bugs for PF driver. > [Patch 9/12 - Patch 12/12] fix issues when change the us mac address of > PF/VF device to an existent one in

Re: [PATCH net-next 00/12] fix some bugs for HNS3 driver

From: Peng Li Date: Sat, 10 Mar 2018 11:29:21 +0800 > This patchset fixes some bugs for HNS3 driver: > [Patch 1/12 - Patch 8/12] fix various bugs for PF driver. > [Patch 9/12 - Patch 12/12] fix issues when change the us mac address of > PF/VF device to an existent one in the mac_vlan table.

Re: [PATCH 1/7] ARM: disallow combining XIP and LTO

On Tue, 20 Feb 2018, Arnd Bergmann wrote: > This fails during deflate_xip_data.sh > > /home/arnd/cross-gcc/bin/arm-linux-gnueabi-objcopy -O binary -R .comment -S > vmlinux arch/arm/boot/xipImage && /bin/bash -c > '/git/arm-soc/arch/arm/boot/deflate_xip_data.sh vmlinux >

Re: [PATCH 1/7] ARM: disallow combining XIP and LTO

On Tue, 20 Feb 2018, Arnd Bergmann wrote: > This fails during deflate_xip_data.sh > > /home/arnd/cross-gcc/bin/arm-linux-gnueabi-objcopy -O binary -R .comment -S > vmlinux arch/arm/boot/xipImage && /bin/bash -c > '/git/arm-soc/arch/arm/boot/deflate_xip_data.sh vmlinux >

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

Just got a wireshark trace - this is a fairly trivial issue (missing the validate negotiate must be signed patch) - I had some trouble getting this version of the kernel running (unrelated issue) and on systems with access to Windows 2016... On Tue, Feb 27, 2018 at 10:33 AM, Srivatsa S. Bhat

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

Just got a wireshark trace - this is a fairly trivial issue (missing the validate negotiate must be signed patch) - I had some trouble getting this version of the kernel running (unrelated issue) and on systems with access to Windows 2016... On Tue, Feb 27, 2018 at 10:33 AM, Srivatsa S. Bhat

Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling

Hi, Marc, On Sun, 2018-03-11 at 12:17 +, Marc Zyngier wrote: > On Sun, 11 Mar 2018 01:55:08 + > Christoffer Dall wrote: > > > > > On Sat, Mar 10, 2018 at 12:20 PM, Marc Zyngier > m> wrote: > > > > > > On Fri, 09 Mar 2018 21:36:12 +, > > >

Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling

Hi, Marc, On Sun, 2018-03-11 at 12:17 +, Marc Zyngier wrote: > On Sun, 11 Mar 2018 01:55:08 + > Christoffer Dall wrote: > > > > > On Sat, Mar 10, 2018 at 12:20 PM, Marc Zyngier > m> wrote: > > > > > > On Fri, 09 Mar 2018 21:36:12 +, > > > Christoffer Dall wrote:   > > > > > > >

Re: [PATCH] arm64: dts: rockchip: assign clock rate for ACLK_VIO

Hi, On Sun, Mar 11, 2018 at 6:50 PM, Shunqian Zheng wrote: > The ACLK_VIO is a parent clock used by a several children, > its suggested clock rate is 400MHz. Right now it gets 400MHz > because it sources from CPLL(800M) and divides by 2 after reset. > It's good not to

Re: [PATCH] arm64: dts: rockchip: assign clock rate for ACLK_VIO

Hi, On Sun, Mar 11, 2018 at 6:50 PM, Shunqian Zheng wrote: > The ACLK_VIO is a parent clock used by a several children, > its suggested clock rate is 400MHz. Right now it gets 400MHz > because it sources from CPLL(800M) and divides by 2 after reset. > It's good not to rely on default values like

Re: [RESEND PATCH] rsi: Remove stack VLA usage

On 03/11/2018 08:43 PM, Tobin C. Harding wrote: The kernel would like to have all stack VLA usage removed[1]. rsi uses a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size is defined using a magic number. We can use a pre-processor defined constant and declare the array to

Re: [RESEND PATCH] rsi: Remove stack VLA usage

On 03/11/2018 08:43 PM, Tobin C. Harding wrote: The kernel would like to have all stack VLA usage removed[1]. rsi uses a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size is defined using a magic number. We can use a pre-processor defined constant and declare the array to

[PATCH V2] ZBOOT: fix stack protector in compressed boot phase

Call __stack_chk_guard_setup() in decompress_kernel() is too late that stack checking always fails for decompress_kernel() itself. So remove __stack_chk_guard_setup() and initialize __stack_chk_guard before we call decompress_kernel(). Original code comes from ARM but also used for MIPS and SH,

[PATCH V2] ZBOOT: fix stack protector in compressed boot phase

Call __stack_chk_guard_setup() in decompress_kernel() is too late that stack checking always fails for decompress_kernel() itself. So remove __stack_chk_guard_setup() and initialize __stack_chk_guard before we call decompress_kernel(). Original code comes from ARM but also used for MIPS and SH,

Re: resend, finish_wait with list_empty_careful maybe fragile or buggy

> Sorry, this is a resend because the previous one was messed > up by my editor and hard to be read. > > void finish_wait( > struct wait_queue_head *wq_head, > struct wait_queue_entry *wq_entry) > { > > ->if (!list_empty_careful(_entry->entry)) { > ->

Re: resend, finish_wait with list_empty_careful maybe fragile or buggy

> Sorry, this is a resend because the previous one was messed > up by my editor and hard to be read. > > void finish_wait( > struct wait_queue_head *wq_head, > struct wait_queue_entry *wq_entry) > { > > ->if (!list_empty_careful(_entry->entry)) { > ->

[PATCH] arm64: dts: rockchip: assign clock rate for ACLK_VIO

The ACLK_VIO is a parent clock used by a several children, its suggested clock rate is 400MHz. Right now it gets 400MHz because it sources from CPLL(800M) and divides by 2 after reset. It's good not to rely on default values like this, so let's explicitly set it. NOTE: it's expected that at least

[PATCH] arm64: dts: rockchip: assign clock rate for ACLK_VIO

The ACLK_VIO is a parent clock used by a several children, its suggested clock rate is 400MHz. Right now it gets 400MHz because it sources from CPLL(800M) and divides by 2 after reset. It's good not to rely on default values like this, so let's explicitly set it. NOTE: it's expected that at least

Re: [PATCH] rcu: Use the proper lockdep annotation in dump_blkd_tasks()

On Fri, Mar 09, 2018 at 09:32:18AM +0800, Boqun Feng wrote: > Sparse reported this: > > | kernel/rcu/tree_plugin.h:814:9: warning: incorrect type in argument 1 > (different modifiers) > | kernel/rcu/tree_plugin.h:814:9:expected struct lockdep_map const *lock > |

Re: [PATCH] rcu: Use the proper lockdep annotation in dump_blkd_tasks()

On Fri, Mar 09, 2018 at 09:32:18AM +0800, Boqun Feng wrote: > Sparse reported this: > > | kernel/rcu/tree_plugin.h:814:9: warning: incorrect type in argument 1 > (different modifiers) > | kernel/rcu/tree_plugin.h:814:9:expected struct lockdep_map const *lock > |

[RESEND PATCH] rsi: Remove stack VLA usage

The kernel would like to have all stack VLA usage removed[1]. rsi uses a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size is defined using a magic number. We can use a pre-processor defined constant and declare the array to maximum size. We add a check before accessing the

[RESEND PATCH] rsi: Remove stack VLA usage

The kernel would like to have all stack VLA usage removed[1]. rsi uses a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size is defined using a magic number. We can use a pre-processor defined constant and declare the array to maximum size. We add a check before accessing the

linux-next: Signed-off-by missing for commit in the battery tree

Hi Sebastian, Commit 5e0dfcbb1194 ("max17042: propagate of_node to power supply device") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell pgplt4KnHnEyF.pgp Description: OpenPGP digital signature

linux-next: Signed-off-by missing for commit in the battery tree

Hi Sebastian, Commit 5e0dfcbb1194 ("max17042: propagate of_node to power supply device") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell pgplt4KnHnEyF.pgp Description: OpenPGP digital signature

[PATCH v2] staging: vchiq_arm: Clear VLA warning

The kernel would like to have all stack VLA usage removed[1]. The array here is fixed (declared with a const variable) but it appears like a VLA to the compiler. Also, currently we are putting 768 bytes on the stack. This function is only called on the error path so performance is not critical,

[PATCH v2] staging: vchiq_arm: Clear VLA warning

The kernel would like to have all stack VLA usage removed[1]. The array here is fixed (declared with a const variable) but it appears like a VLA to the compiler. Also, currently we are putting 768 bytes on the stack. This function is only called on the error path so performance is not critical,

Re: [PATCH] net/9p: avoid -ERESTARTSYS leak to userspace

On 2018/3/10 4:41, Greg Kurz wrote: > If it was interrupted by a signal, the 9p client may need to send some > more requests to the server for cleanup before returning to userspace. > > To avoid such a last minute request to be interrupted right away, the > client memorizes if a signal is

Re: [PATCH] net/9p: avoid -ERESTARTSYS leak to userspace

On 2018/3/10 4:41, Greg Kurz wrote: > If it was interrupted by a signal, the 9p client may need to send some > more requests to the server for cleanup before returning to userspace. > > To avoid such a last minute request to be interrupted right away, the > client memorizes if a signal is

<    1   2   3   4   5   6   7   8   9   10   >