From: Dan Williams <dan.j.williams@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>, Tony Luck <tony.luck@intel.com>, 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 12:29:12 -0700 [thread overview] Message-ID: <CAPcyv4iTaBNPMwqUwas+J4rxd867QL7JnQBYB8NKnYaTA-R_Tw@mail.gmail.com> (raw) In-Reply-To: <CAHk-=wgcc=5kiph7o+aBZoWBCbu=9nQDQtD41DvuRRrqixohUA@mail.gmail.com> On Mon, Apr 20, 2020 at 12:13 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Apr 20, 2020 at 11:20 AM Dan Williams <dan.j.williams@intel.com> wrote: [..] > I really really detest the whole mcsafe garbage. And I absolutely > *ABHOR* how nobody inside of Intel has apparently ever questioned the > brokenness at a really fundamental level. > > That "I throw my hands in the air and just give up" thing is a > disease. It's absolutely not "what else could we do". So I grew up in the early part of my career validating ARM CPUs where a data-abort was either precise or imprecise and the precise error could be handled like a page fault as you know which instruction faulted and how to restart the thread. So I didn't take x86 CPU designers' word for it, I honestly thought that "hmm the x86 machine check thingy looks like it's trying to implement precise vs imprecise data-aborts, and precise / synchronous is maybe a good thing because it's akin to a page fault". 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. _______________________________________________ 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: Dan Williams <dan.j.williams@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>, Tony Luck <tony.luck@intel.com>, 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 12:29:12 -0700 [thread overview] Message-ID: <CAPcyv4iTaBNPMwqUwas+J4rxd867QL7JnQBYB8NKnYaTA-R_Tw@mail.gmail.com> (raw) In-Reply-To: <CAHk-=wgcc=5kiph7o+aBZoWBCbu=9nQDQtD41DvuRRrqixohUA@mail.gmail.com> On Mon, Apr 20, 2020 at 12:13 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Apr 20, 2020 at 11:20 AM Dan Williams <dan.j.williams@intel.com> wrote: [..] > I really really detest the whole mcsafe garbage. And I absolutely > *ABHOR* how nobody inside of Intel has apparently ever questioned the > brokenness at a really fundamental level. > > That "I throw my hands in the air and just give up" thing is a > disease. It's absolutely not "what else could we do". So I grew up in the early part of my career validating ARM CPUs where a data-abort was either precise or imprecise and the precise error could be handled like a page fault as you know which instruction faulted and how to restart the thread. So I didn't take x86 CPU designers' word for it, I honestly thought that "hmm the x86 machine check thingy looks like it's trying to implement precise vs imprecise data-aborts, and precise / synchronous is maybe a good thing because it's akin to a page fault". 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.
next prev parent reply other threads:[~2020-04-20 19:30 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 [this message] 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 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=CAPcyv4iTaBNPMwqUwas+J4rxd867QL7JnQBYB8NKnYaTA-R_Tw@mail.gmail.com \ --to=dan.j.williams@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=tony.luck@intel.com \ --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: linkBe 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.