All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: Borislav Petkov <bp@suse.de>, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, aravind.gopalakrishnan@amd.com,
	tglx@linutronix.de, linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/urgent] x86, cpu, amd: Add workaround for family 16h, erratum 793
Date: Wed, 15 Jan 2014 19:38:07 +0100	[thread overview]
Message-ID: <20140115183807.GA23486@gmail.com> (raw)
In-Reply-To: <52D69291.8080003@linux.intel.com>


* H. Peter Anvin <hpa@linux.intel.com> wrote:

> On 01/15/2014 05:36 AM, Borislav Petkov wrote:
> >>
> >> msr_read() would essentially map to rdmsr_safe(). Each method has a
> >> return value that can be checked for failure.
> > 
> > I'm not sure we want to use the _safe() variants by default as it 
> > would generate the exception tables even in cases where they're 
> > clearly not needed.

I don't think those new methods should be inline functions - thus 
there will be only one exception entry for each.

> It would be particularly silly if what you end up with is in effect 
> to wrap msr_read/write() in a BUG_ON(), which is the effect of the 
> current (trapping) form.  There is something to be said for hard 
> errors.

Right, the fact that most of our MSR accesses today are 
crash-on-failure, which happens to trigger crashes on a regular 
schedule, where most of the crashes are 'harmless' situation except 
that they crash the systems for good.

So I think defaulting to soft failures is the right approach.

Thanks,

	Ingo

  reply	other threads:[~2014-01-15 18:38 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-14 11:41 AMD errata 793 (CVE-2013-6885) needs a workaround in Linux? Henrique de Moraes Holschuh
2014-01-14 11:55 ` Borislav Petkov
2014-01-14 15:14   ` H. Peter Anvin
2014-01-14 15:35     ` Borislav Petkov
2014-01-14 16:27       ` [PATCH] x86, CPU, AMD: Add workaround for family 16h, erratum 793 Borislav Petkov
2014-01-14 16:30         ` H. Peter Anvin
2014-01-14 16:42           ` Borislav Petkov
2014-01-14 17:46             ` H. Peter Anvin
2014-01-14 23:07               ` [PATCH -v1.1] " Borislav Petkov
2014-01-15  0:38                 ` H. Peter Anvin
2014-01-15 11:10                   ` [PATCH -v1.2] " Borislav Petkov
2014-01-15  0:45                 ` [tip:x86/urgent] x86, cpu, amd: " tip-bot for Borislav Petkov
2014-01-15  0:54                   ` H. Peter Anvin
2014-01-15  6:28                     ` Ingo Molnar
2014-01-15 13:36                       ` Borislav Petkov
2014-01-15 13:52                         ` H. Peter Anvin
2014-01-15 18:38                           ` Ingo Molnar [this message]
2014-01-16  4:11                             ` H. Peter Anvin
     [not found]         ` <52D59ACC.3090100@amd.com>
2014-01-14 20:38           ` [PATCH] x86, CPU, AMD: " Borislav Petkov
2014-01-16 17:58             ` Aravind Gopalakrishnan
2014-01-16 18:10               ` Borislav Petkov
2014-01-17  0:21               ` Henrique de Moraes Holschuh
2014-01-17  0:25                 ` H. Peter Anvin
2014-01-17 10:18                 ` Borislav Petkov
2014-01-17 16:23                   ` H. Peter Anvin
2014-01-17 17:02                     ` Borislav Petkov
2014-01-17 17:36                       ` Aravind Gopalakrishnan
2014-01-17 17:42                       ` H. Peter Anvin
2014-01-17 18:05                         ` Aravind Gopalakrishnan
2014-01-17 18:25                           ` Borislav Petkov
2014-01-17 22:28         ` Pavel Machek
2014-01-17 22:50           ` Borislav Petkov
2014-01-17 22:51             ` H. Peter Anvin
2014-01-17 22:57               ` Borislav Petkov
2014-01-18  0:29               ` Pavel Machek
2014-01-18  1:21                 ` H. Peter Anvin
2014-01-18  2:01                   ` Pavel Machek
2014-01-18 10:42                     ` Borislav Petkov
2014-01-18 11:08                       ` Pavel Machek
2014-01-18 11:26                         ` Borislav Petkov
2014-01-18 11:31                           ` Pavel Machek

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=20140115183807.GA23486@gmail.com \
    --to=mingo@kernel.org \
    --cc=aravind.gopalakrishnan@amd.com \
    --cc=bp@suse.de \
    --cc=hpa@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.