All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: X86 ML <x86@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Jann Horn <jannh@google.com>, LKML <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Nadav Amit <nadav.amit@gmail.com>
Subject: Re: [PATCH] x86/nmi: Fix some races in NMI uaccess
Date: Tue, 28 Aug 2018 09:50:53 -0400	[thread overview]
Message-ID: <9f09dcbfa27004fc69dccf8039857f06438018f5.camel@surriel.com> (raw)
In-Reply-To: <CALCETrUMeV=P89msPuVuiWEw-MdZQZ9t0rTMgY8P91Q8tQvnXQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Mon, 2018-08-27 at 19:10 -0700, Andy Lutomirski wrote:
> On Mon, Aug 27, 2018 at 6:31 PM, Rik van Riel <riel@surriel.com>
> wrote:
> 
> > What is special about this path wrt nmi_uaccess_ok that is
> > not also true for the need_flush branch right above it?
> > 
> > What am I missing?
> 
> Nothing.  My patch is buggy.  ETOLITTLESLEEP.
> 
> I could drop this part of the patch entirely.  Or I could drop the
> loaded_mm->pgd == __va(read_cr3_pa() check and instead make sure that
> loaded_mm is NULL at any point at which loaded_mm might not match
> CR3.
> The latter will be faster in any (hypothetical) virtualization
> environment where CR3 reads trap.  I don't know if we have any such
> cases where perf works and we care about performance, though.

Moving that loaded_mm = NULL assignment up a few
lines, so it comes before the "if (need_flush)"
test and covers both branches should cover that,
indeed.

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-08-28 13:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-27 23:04 [PATCH] x86/nmi: Fix some races in NMI uaccess Andy Lutomirski
2018-08-27 23:12 ` Jann Horn
2018-08-27 23:25   ` Andy Lutomirski
2018-08-27 23:34     ` Jann Horn
2018-08-28  1:31 ` Rik van Riel
2018-08-28  2:10   ` Andy Lutomirski
2018-08-28 13:50     ` Rik van Riel [this message]
2018-08-28 17:56 ` [PATCH v2] " Rik van Riel
2018-08-29  3:46   ` Andy Lutomirski
2018-08-29 15:17     ` Rik van Riel
2018-08-29 15:36       ` Andy Lutomirski
2018-08-29 15:49         ` Rik van Riel
2018-08-29 16:14           ` Andy Lutomirski

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=9f09dcbfa27004fc69dccf8039857f06438018f5.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=bp@alien8.de \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=x86@kernel.org \
    /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.