linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cyril Bur <cyrilbur@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Valentin Rothberg <valentinrothberg@gmail.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc: process.c: fix Kconfig typo
Date: Thu, 27 Oct 2016 12:08:31 +1100	[thread overview]
Message-ID: <1477530511.2313.1.camel@gmail.com> (raw)
In-Reply-To: <878ttby7vh.fsf@concordia.ellerman.id.au>

On Wed, 2016-10-26 at 16:52 +1100, Michael Ellerman wrote:
> Cyril Bur <cyrilbur@gmail.com> writes:
> 
> > On Wed, 2016-10-05 at 07:57 +0200, Valentin Rothberg wrote:
> > > s/ALIVEC/ALTIVEC/
> > > 
> > 
> > Oops, nice catch
> > 
> > > Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com>
> > 
> > Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
> 
> How did we not notice? Sounds like we need a new selftest.
> 

Indeed...

Here is probably a good place to say why we didn't catch it and under
what circumstances this will have a negative effect.

If a thread performs and transaction with altivec and then gets
preempted for whatever reason, this bug may cause the kernel to not
reenable altivec when that thread runs again. This will result in an
altivec unavailable fault, when these faults happen inside a user
transaction the kernel has no choice but enable altivec and doom the
transaction.

The result is that transactions using altivec may get aborted more 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)...


Cyril

> Looks like this should have:
> 
> Fixes: dc16b553c949 ("powerpc: Always restore FPU/VEC/VSX if hardware
> transactional memory in use")
> 
> 
> And I guess I need to start running checkkconfigsymbols.py on every
> commit.
> 
> cheers

  parent reply	other threads:[~2016-10-27  1:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-05  5:57 [PATCH] powerpc: process.c: fix Kconfig typo Valentin Rothberg
2016-10-05 22:54 ` Cyril Bur
     [not found]   ` <878ttby7vh.fsf@concordia.ellerman.id.au>
2016-10-26  6:25     ` Valentin Rothberg
2016-10-26 10:40       ` Michael Ellerman
2016-10-26 10:43         ` Valentin Rothberg
2016-10-27  0:11           ` Michael Ellerman
2016-10-27  1:08     ` Cyril Bur [this message]
2016-10-27 11:41 ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1477530511.2313.1.camel@gmail.com \
    --to=cyrilbur@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=valentinrothberg@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).