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 page covering poisoned pmem
>> > would complicate the 'clear badblocks' im
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' implementation.
> Ugh, ok.
> I guess the good news is that your patc
On Wed, May 2, 2018 at 1:30 AM, Borislav Petkov wrote:
> 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 reco
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 talked
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 cacheline boundaries? And if it does,
> who
>> > designed it, a
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 think this is an FAQ from the
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' implementation.
>
> Ugh, ok.
>
> I guess the good news is that your pat
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
affect anything else.
But can
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 indirection games we can play here
>>> to poison a page and map in another page. The ma
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 page is 1:1
>> associated with the filesystem block and p
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 talking page cache indirection
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 patch teaches the
>> machine check handler how to recover cop
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 unmap the page and remap a ne
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 latter.
>
>> If it's the latter, MCS error handling, I don
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 copy_to_iter_mcsafe().
So t
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
>> > wrote:
>> >
>> >> The result of the bypass is that the kernel treats
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
> > wrote:
> >
> >> The result of the bypass is that the kernel treats machine checks
during
> >> read as system fatal (reboot) when they
On Tue, May 1, 2018 at 2:05 PM, Linus Torvalds
wrote:
> 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 r
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. Prevent
> this fatal condition by
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() an
20 matches
Mail list logo
