From: "Luck, Tony" <tony.luck@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
stable <stable@vger.kernel.org>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Erwin Tsaur <erwin.tsaur@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast
Date: Mon, 20 Apr 2020 13:23:32 -0700 [thread overview]
Message-ID: <20200420202332.GA30160@agluck-desk2.amr.corp.intel.com> (raw)
In-Reply-To: <CAHk-=wgOUOveRe8=iFWw0S1LSDEjSfQ-4bM64eiXdGj4n7Omng@mail.gmail.com>
On Mon, Apr 20, 2020 at 01:07:09PM -0700, Linus Torvalds wrote:
> On Mon, Apr 20, 2020 at 12:29 PM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > I didn't consider asynchronous to be
> > better because that means there is a gap between when the data
> > corruption is detected and when it might escape the system that some
> > external agent could trust the result and start acting on before the
> > asynchronous signal is delivered.
>
> The thing is, absolutely nobody cares whether you start acting on the
> wrong data or not.
I think they do. If the result of the wrong data has already
been sent out the network before you process the signal, then you
will need far smarter application software than has ever been written
to hunt it down and stop the spread of the bogus result.
Stopping dead on the instruction before it consumes the data
means you can "recover" by killing just one process, or just one
VMM guest.
I'm in total agreement the machine check (especially broadcast)
was a bad choice for how to "stop on a dime". But I can't see
how you could possibly decide what to do if you let thousands
of instructions retire based on a bad data value before you even
know that it happened.
-Tony
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: "Luck, Tony" <tony.luck@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
Andy Lutomirski <luto@amacapital.net>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, X86 ML <x86@kernel.org>,
stable <stable@vger.kernel.org>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Erwin Tsaur <erwin.tsaur@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast
Date: Mon, 20 Apr 2020 13:23:32 -0700 [thread overview]
Message-ID: <20200420202332.GA30160@agluck-desk2.amr.corp.intel.com> (raw)
In-Reply-To: <CAHk-=wgOUOveRe8=iFWw0S1LSDEjSfQ-4bM64eiXdGj4n7Omng@mail.gmail.com>
On Mon, Apr 20, 2020 at 01:07:09PM -0700, Linus Torvalds wrote:
> On Mon, Apr 20, 2020 at 12:29 PM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > I didn't consider asynchronous to be
> > better because that means there is a gap between when the data
> > corruption is detected and when it might escape the system that some
> > external agent could trust the result and start acting on before the
> > asynchronous signal is delivered.
>
> The thing is, absolutely nobody cares whether you start acting on the
> wrong data or not.
I think they do. If the result of the wrong data has already
been sent out the network before you process the signal, then you
will need far smarter application software than has ever been written
to hunt it down and stop the spread of the bogus result.
Stopping dead on the instruction before it consumes the data
means you can "recover" by killing just one process, or just one
VMM guest.
I'm in total agreement the machine check (especially broadcast)
was a bad choice for how to "stop on a dime". But I can't see
how you could possibly decide what to do if you let thousands
of instructions retire based on a bad data value before you even
know that it happened.
-Tony
next prev parent reply other threads:[~2020-04-20 20:23 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-18 20:30 [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast Andy Lutomirski
2020-04-18 20:30 ` Andy Lutomirski
2020-04-18 20:52 ` Linus Torvalds
2020-04-18 20:52 ` Linus Torvalds
2020-04-20 5:08 ` Dan Williams
2020-04-20 5:08 ` Dan Williams
2020-04-20 17:28 ` Linus Torvalds
2020-04-20 17:28 ` Linus Torvalds
2020-04-20 18:20 ` Dan Williams
2020-04-20 18:20 ` Dan Williams
2020-04-20 19:05 ` Linus Torvalds
2020-04-20 19:05 ` Linus Torvalds
2020-04-20 19:29 ` Dan Williams
2020-04-20 19:29 ` Dan Williams
2020-04-20 20:07 ` Linus Torvalds
2020-04-20 20:07 ` Linus Torvalds
2020-04-20 20:23 ` Luck, Tony [this message]
2020-04-20 20:23 ` Luck, Tony
2020-04-20 20:27 ` Linus Torvalds
2020-04-20 20:27 ` Linus Torvalds
2020-04-20 20:45 ` Luck, Tony
2020-04-20 20:45 ` Luck, Tony
2020-04-20 20:56 ` Linus Torvalds
2020-04-20 20:56 ` Linus Torvalds
2020-04-20 20:24 ` Dan Williams
2020-04-20 20:24 ` Dan Williams
2020-04-20 20:46 ` Linus Torvalds
2020-04-20 20:46 ` Linus Torvalds
2020-04-20 20:57 ` Luck, Tony
2020-04-20 20:57 ` Luck, Tony
2020-04-20 21:16 ` Linus Torvalds
2020-04-20 21:16 ` Linus Torvalds
2020-10-06 9:57 ` [tip: ras/core] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}() tip-bot2 for Dan Williams
2020-10-07 11:14 ` Borislav Petkov
2020-10-07 16:45 ` Borislav Petkov
2020-10-07 17:03 ` Borislav Petkov
2020-10-07 18:53 ` Dan Williams
2020-10-07 19:25 ` Borislav Petkov
2020-10-08 16:59 ` Dan Williams
2020-10-08 17:08 ` Borislav Petkov
2020-10-07 17:51 ` Dan Williams
2020-10-07 18:24 ` [PATCH] x86/mce: Gate copy_mc_fragile() export by CONFIG_COPY_MC_TEST=y Dan Williams
2020-10-07 18:24 ` Dan Williams
2020-10-08 9:01 ` [tip: ras/core] x86/mce: Allow for copy_mc_fragile symbol checksum to be generated tip-bot2 for Borislav Petkov
-- strict thread matches above, loose matches on Subject: below --
2020-04-10 17:49 [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast Dan Williams
2020-04-10 17:49 ` Dan Williams
2020-04-18 0:12 ` Dan Williams
2020-04-18 0:12 ` Dan Williams
2020-04-18 19:42 ` Linus Torvalds
2020-04-18 19:42 ` Linus Torvalds
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=20200420202332.GA30160@agluck-desk2.amr.corp.intel.com \
--to=tony.luck@intel.com \
--cc=bp@alien8.de \
--cc=erwin.tsaur@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.