linux-kernel - Re: [RFC PATCH] dax: add badblocks check to Device DAX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPcyv4gthc8Gc7SUyxqecDrd+dtOfOzY19bs5sY1qMepQKh=kQ@mail.gmail.com>
Date:   Wed, 3 May 2017 09:30:21 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Kani, Toshimitsu" <toshi.kani@....com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>
Subject: Re: [RFC PATCH] dax: add badblocks check to Device DAX

On Wed, May 3, 2017 at 9:09 AM, Kani, Toshimitsu <toshi.kani@....com> wrote:
> On Wed, 2017-05-03 at 08:52 -0700, Dan Williams wrote:
>> On Wed, May 3, 2017 at 8:31 AM, Toshi Kani <toshi.kani@....com>
>> wrote:
>> > This is a RFC patch for seeking suggestions.  It adds support of
>> > badblocks check in Device DAX by using region-level badblocks list.
>> > This patch is only briefly tested.
>> >
>> > device_dax is a well-isolated self-contained module as it calls
>> > alloc_dax() with dev_dax, which is private to device_dax.  For
>> > checking badblocks, it needs to call dax_pmem to check with
>> > region-level badblocks.
>> >
>> > This patch attempts to keep device_dax self-contained.  It adds
>> > check_error() to dax_operations, and dax_check_error() as a stub
>> > with *dev_dax and *dev pointers to convey it to dax_pmem.  I am
>> > wondering if this is the right direction, or we should change the
>> > modularity to let dax_pmem call alloc_dax() with its dax_pmem (or
>> > I completely missed something).
>>
>> The problem is that device-dax guarantees a given fault granularity.
>> To make that guarantee we can't fallback from 1G or 2M mappings due
>> to an error. We also can't reasonably go the other way and fail
>> mappings that contain a badblock because that would change the blast
>> radius of a media error to the fault size.
>
> Does it mean we expect users to have CPUs with MCE recovery for Device
> DAX?  Can we add an attributes like allow error-check & fall-back?

Yes, without MCE recovery device-dax mappings that consume errors will
reboot. If an application needs the kernel protection it should be
using filesystem-dax.