Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-02 Thread Dan Williams
On Wed, May 2, 2018 at 9:19 AM, Andy Lutomirski wrote: > On Tue, May 1, 2018 at 8:34 PM Linus Torvalds > > wrote: > >> On Tue, May 1, 2018 at 8:22 PM Dan Williams >> wrote: > >> > All that to say that having a typical RAM

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-02 Thread Andy Lutomirski
On Tue, May 1, 2018 at 8:34 PM Linus Torvalds wrote: > On Tue, May 1, 2018 at 8:22 PM Dan Williams > wrote: > > All that to say that having a typical RAM page covering poisoned pmem > > would complicate the 'clear badblocks'

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-02 Thread Borislav Petkov
On Tue, May 01, 2018 at 07:25:57PM -0700, Dan Williams wrote: > Right, but the only way to make MCE non-fatal is to teach the machine > check handler about recoverable conditions. This patch teaches the > machine check handler how to recover copy_to_iter() errors. Yeah, about that: maybe we

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Dan Williams
On Tue, May 1, 2018 at 9:14 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 9:00 PM Dan Williams > wrote: >> > >> > I have some dim memory of "rep movs doesn't work well for pmem", but > does >> > it *seriously* need unrolling to

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Linus Torvalds
On Tue, May 1, 2018 at 9:00 PM Dan Williams wrote: > > > > I have some dim memory of "rep movs doesn't work well for pmem", but does > > it *seriously* need unrolling to cacheline boundaries? And if it does, who > > designed it, and why is anybody using it? > > > I

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Dan Williams
On Tue, May 1, 2018 at 8:33 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 8:22 PM Dan Williams > wrote: > >> All that to say that having a typical RAM page covering poisoned pmem >> would complicate the 'clear badblocks'

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Linus Torvalds
On Tue, May 1, 2018 at 8:22 PM Dan Williams wrote: > All that to say that having a typical RAM page covering poisoned pmem > would complicate the 'clear badblocks' implementation. Ugh, ok. I guess the good news is that your patches aren't so big, and don't really

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Dan Williams
On Tue, May 1, 2018 at 8:20 PM, Dan Williams wrote: > On Tue, May 1, 2018 at 8:13 PM, Linus Torvalds > wrote: >> On Tue, May 1, 2018 at 8:03 PM Dan Williams >> wrote: >> >>> Because dax. There's no page cache

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Dan Williams
On Tue, May 1, 2018 at 8:13 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 8:03 PM Dan Williams > wrote: > >> Because dax. There's no page cache indirection games we can play here >> to poison a page and map in another page. The mapped

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Linus Torvalds
On Tue, May 1, 2018 at 8:03 PM Dan Williams wrote: > Because dax. There's no page cache indirection games we can play here > to poison a page and map in another page. The mapped page is 1:1 > associated with the filesystem block and physical memory address. I'm not

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Dan Williams
On Tue, May 1, 2018 at 7:53 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 7:26 PM Dan Williams > wrote: > >> Right, but the only way to make MCE non-fatal is to teach the machine >> check handler about recoverable conditions. This

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Linus Torvalds
On Tue, May 1, 2018 at 7:26 PM Dan Williams wrote: > Right, but the only way to make MCE non-fatal is to teach the machine > check handler about recoverable conditions. This patch teaches the > machine check handler how to recover copy_to_iter() errors. Why not just

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Dan Williams
On Tue, May 1, 2018 at 5:09 PM, Linus Torvalds wrote: > On Tue, May 1, 2018 at 4:03 PM Dan Williams > wrote: > >> I'm confused. Are you talking about getting rid of the block-layer >> bypass or changing how MCS errors are handled? > > The

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Linus Torvalds
On Tue, May 1, 2018 at 4:03 PM Dan Williams wrote: > I'm confused. Are you talking about getting rid of the block-layer > bypass or changing how MCS errors are handled? The latter. > If it's the latter, MCS error handling, I don't see how get > around something like

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Dan Williams
On Tue, May 1, 2018 at 4:28 PM, Andy Lutomirski wrote: > On Tue, May 1, 2018 at 4:02 PM Dan Williams > wrote: > >> On Tue, May 1, 2018 at 2:05 PM, Linus Torvalds >> wrote: >> > On Tue, May 1, 2018 at 1:55 PM Dan Williams

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Linus Torvalds
On Tue, May 1, 2018 at 1:55 PM Dan Williams wrote: > The result of the bypass is that the kernel treats machine checks during > read as system fatal (reboot) when they could simply be flagged as an > I/O error, similar to performing reads through the pmem driver.

[PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

2018-05-01 Thread Dan Williams
Currently memcpy_mcsafe() is only deployed in the pmem driver when reading through a /dev/pmemX block device. However, a filesystem in dax mode mounted on a /dev/pmemX block device will bypass the block layer and the driver for reads. The filesystem-dax (fsdax) read case uses dax_direct_access()