ACK: [SRU][Artful][PATCH 0/2] Fixes for LP:1721070

Colin Ian King colin.king at canonical.com
Mon Oct 9 11:18:30 UTC 2017


On 06/10/17 18:26, Joseph Salisbury wrote:
> BugLink: http://bugs.launchpad.net/bugs/1721070
> 
> == SRU Justification ==
> POWER9 DD2.1 and earlier has an issue where some cache inhibited
> vector load will return bad data. The fix is two part, one
> firmware/microcode part triggers HMI interrupts when hitting such
> loads, the other part is commit 5080332c2c89 from linux-next which then 
> emulates the instructions in Linux.
> 
> The affected instructions are limited to lxvd2x, lxvw4x, lxvb16x and
> lxvh8x.
>   
> Commit ccd3cd361341 is needed as a prereq, and is in mainline as of 4.14-rc1.
> Commit 5080332c2c89 is still in linux-next.  Both commts are clean cherry
> picks in Artful.  This fix is also need in Zesty, but Zesty needs an addition
> prereq, so a seperate SRU request will be sent.
> 
>  
> == Fixes ==
> ccd3cd361341 ("powerpc/mce: Move 64-bit machine check code into mce.c")
> 5080332c2c89 ("powerpc/64s: Add workaround for P9 vector CI load issue") 
> 
> == Regression Potential ==
> These commits are specific to powerpc and have been tested by IBM.
> 
> == Test Case == 
> A test kernel was built with these patches and tested by the original bug reporter.
> The bug reporter states the test kernel resolved the bug.
> 
> 
> Michael Ellerman (1):
>   powerpc/mce: Move 64-bit machine check code into mce.c
> 
> Michael Neuling (1):
>   powerpc/64s: Add workaround for P9 vector CI load issue
> 
>  arch/powerpc/include/asm/emulated_ops.h |   4 +
>  arch/powerpc/include/asm/paca.h         |   1 +
>  arch/powerpc/include/asm/uaccess.h      |  17 +++
>  arch/powerpc/kernel/exceptions-64s.S    |  16 ++-
>  arch/powerpc/kernel/mce.c               |  61 +++++++++
>  arch/powerpc/kernel/traps.c             | 234 +++++++++++++++++++++++++++-----
>  arch/powerpc/platforms/powernv/smp.c    |   7 +
>  7 files changed, 303 insertions(+), 37 deletions(-)
> 
These second patch is little hairy to say the least (and from linux-next
too.  The back ports look good though and it it seems to
fix the problem with positive test results.  Since this touches one
specific architecture and we have positive test results and the
backports look OK, I'll ACK these.

Acked-by: Colin Ian King <colin.king at canonical.com>




More information about the kernel-team mailing list