Kernel: Fix Transactional memory config typo
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Yakkety |
Fix Released
|
Undecided
|
Tim Gardner | ||
Zesty |
Fix Released
|
High
|
Unassigned |
Bug Description
Canonical,
Please include the following fix on 16.10. This typo is causing some issue on TM.
The patches that causes this problem is ec2a04841b78537
commit 39715bf972ed4fe
Author: Valentin Rothberg <email address hidden>
Date: Wed Oct 5 07:57:26 2016 +0200
powerpc/
It should be ALTIVEC, not ALIVEC.
Cyril explains: If a thread performs a transaction with altivec and then
gets preempted for whatever reason, this bug may cause the kernel to not
re-enable altivec when that thread runs again. This will result in an
altivec unavailable fault, when that fault happens inside a user
transaction the kernel has no choice but to enable altivec and doom the
transaction.
The result is that transactions using altivec may get aborted more often
than they should.
The difficulty in catching this with a selftest is my deliberate use of
the word may above. Optimisations to avoid FPU/altivec/VSX faults mean
that the kernel will always leave them on for 255 switches. This code
prevents the kernel turning it off if it got to the 256th switch (and
userspace was transactional).
Fixes: dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use")
Reviewed-by: Cyril Bur <email address hidden>
Signed-off-by: Valentin Rothberg <email address hidden>
Signed-off-by: Michael Ellerman <email address hidden>
tags: | added: architecture-ppc64le bugnameltc-152112 severity-high targetmilestone-inin1610 |
Changed in ubuntu: | |
assignee: | nobody → Taco Screen team (taco-screen-team) |
affects: | ubuntu → linux (Ubuntu) |
Changed in linux (Ubuntu): | |
assignee: | Taco Screen team (taco-screen-team) → Canonical Kernel Team (canonical-kernel-team) |
importance: | Undecided → High |
status: | New → Triaged |
Changed in linux (Ubuntu Yakkety): | |
status: | In Progress → Fix Committed |
tags: |
added: verification-done-yakkety removed: verification-needed-yakkety |
Leann,
Patch to fix an error caused by a typo, please have the Kernel Team
evaluate.
Thanks.
On 03/01/2017 07:29 AM, Launchpad Bug Tracker wrote: 3a6379af6603220 1a2b90922b on yakkety-ubuntu repo. e18fe5409609a97 1fb16b1771 ppc64le bugnameltc-152112 severity-high targetmilestone -inin1610
> bugproxy (bugproxy) has assigned this bug to you for Ubuntu:
>
> Canonical,
>
> Please include the following fix on 16.10. This typo is causing some issue on TM.
> The patches that causes this problem is ec2a04841b78537
>
> commit 39715bf972ed4fe
> Author: Valentin Rothberg <email address hidden>
> Date: Wed Oct 5 07:57:26 2016 +0200
>
> powerpc/process: Fix CONFIG_ALIVEC typo in restore_tm_state()
>
> It should be ALTIVEC, not ALIVEC.
>
> Cyril explains: If a thread performs a transaction with altivec and then
> gets preempted for whatever reason, this bug may cause the kernel to not
> re-enable altivec when that thread runs again. This will result in an
> altivec unavailable fault, when that fault happens inside a user
> transaction the kernel has no choice but to enable altivec and doom the
> transaction.
>
> The result is that transactions using altivec may get aborted more often
> than they should.
>
> The difficulty in catching this with a selftest is my deliberate use of
> the word may above. Optimisations to avoid FPU/altivec/VSX faults mean
> that the kernel will always leave them on for 255 switches. This code
> prevents the kernel turning it off if it got to the 256th switch (and
> userspace was transactional).
>
> Fixes: dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use")
> Reviewed-by: Cyril Bur <email address hidden>
> Signed-off-by: Valentin Rothberg <email address hidden>
> Signed-off-by: Michael Ellerman <email address hidden>
>
> ** Affects: ubuntu
> Importance: Undecided
> Assignee: Taco Screen team (taco-screen-team)
> Status: New
>
>
> ** Tags: architecture-
--
Michael Hohnbaum
OIL Program Manager
Power (ppc64el) Development Project Manager
Canonical, Ltd.