From patchwork Wed Mar 1 20:17:34 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 734358 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3vYRZh3mdRz9s7q; Thu, 2 Mar 2017 07:17:48 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical-com.20150623.gappssmtp.com header.i=@canonical-com.20150623.gappssmtp.com header.b="xdI0P3uV"; dkim-atps=neutral Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.76) (envelope-from ) id 1cjAgy-0000Sz-EN; Wed, 01 Mar 2017 20:17:44 +0000 Received: from mail-io0-f173.google.com ([209.85.223.173]) by huckleberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1cjAgt-0000Sp-GB for kernel-team@lists.ubuntu.com; Wed, 01 Mar 2017 20:17:39 +0000 Received: by mail-io0-f173.google.com with SMTP id 90so39299883ios.1 for ; Wed, 01 Mar 2017 12:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id; bh=OJQCI1jgwmza75mlUtODDBLY9PMuD9JXfixDnDi2wdI=; b=xdI0P3uVSnUEbOQDqUM/QJQbsru9sQbEXP75hNY4JMcx1dHrCGTyJIRUqCTkQm8D9e 62WerkKVx2PYuK/KPJ2hsqUWsYtnBEOK5zksnP3OLulI9UdpcHy4imyYzZLOXabM8N3m og1HYJXRToGw28RCsjwtUg/jMz6oT7JKCNO+OWnwtSQmIJYVqQESHNx6dtgq6QsaOywp mfRPdTQQBuUOiV9B5lSbbaz94Eq07z52IJhQQRpzn1t19MASgtXXZaIak5h/s0OBlm8S 1wRnFHiNLPI83rqHqulBsdGHXYb0bi28ecWpqju5TRVagMfn3/jl4b14HSPu6zfHMOKA L1sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id; bh=OJQCI1jgwmza75mlUtODDBLY9PMuD9JXfixDnDi2wdI=; b=olqxicLXM51B1PAhh7DaG+S9khCPiUOofPNYfVzSDxcK7BmMDo3LVW7OLN2ttsdcS8 G2xWVKMnhUOy+skrqz99MXqRFggA3S4weyvUPtUzrblhbv781PnewIL4/u9x+OWxtJkA sTmj5ZnQixNVJnPWY/MzlZJln+9MGXbCnsjMBWTonzovDjw17/6kMLHVureGEFnt/6I2 lFzJiICCG6JFBcW9cjizElUOoyNbYxkVXLlMqZu4LG21rPIBwKnoMRCE3hsOt4H5JeUu iCmqaEafjumQFq0lbH6DE15hgaguVDJDfEQzWypZ/iKl4zsrJyh6Ygn4lJeNigtJtyjI Y7jA== X-Gm-Message-State: AMke39mXbfKug37Z+gXmz7Y4PqruVD4cSRft+LP2pVy+QQHnJQ0EB9fJEAkaOqVM/0HnTJV6 X-Received: by 10.107.47.5 with SMTP id j5mr9849814ioo.231.1488399458138; Wed, 01 Mar 2017 12:17:38 -0800 (PST) Received: from localhost.localdomain (host-98-127-250-84.bln-mt.client.bresnan.net. [98.127.250.84]) by smtp.gmail.com with ESMTPSA id l17sm2511340ioi.60.2017.03.01.12.17.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Mar 2017 12:17:37 -0800 (PST) From: Tim Gardner To: kernel-team@lists.ubuntu.com Subject: [PATCH Yakkety SRU] powerpc/process: Fix CONFIG_ALIVEC typo in restore_tm_state() Date: Wed, 1 Mar 2017 13:17:34 -0700 Message-Id: <1488399454-18377-1-git-send-email-tim.gardner@canonical.com> X-Mailer: git-send-email 2.7.4 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.14 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: kernel-team-bounces@lists.ubuntu.com From: Valentin Rothberg BugLink: http://bugs.launchpad.net/bugs/1669023 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 Signed-off-by: Valentin Rothberg Signed-off-by: Michael Ellerman (cherry picked from commit 39715bf972ed4fee18fe5409609a971fb16b1771) Signed-off-by: Tim Gardner --- arch/powerpc/kernel/process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index bb5ed9e..b7ba944 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -995,7 +995,7 @@ void restore_tm_state(struct pt_regs *regs) /* Ensure that restore_math() will restore */ if (msr_diff & MSR_FP) current->thread.load_fp = 1; -#ifdef CONFIG_ALIVEC +#ifdef CONFIG_ALTIVEC if (cpu_has_feature(CPU_FTR_ALTIVEC) && msr_diff & MSR_VEC) current->thread.load_vec = 1; #endif