linux-kernel - Re: [PATCH 0/9] Allow persistent memory to be used like normal RAM

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: <CAPcyv4jcgRTR-NnHPpsLm=z8uSLJZYN530nGm5f9k6Q3WGHr0g@mail.gmail.com>
Date:   Tue, 23 Oct 2018 11:58:06 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     "Elliott, Robert (Persistent Memory)" <elliott@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Michal Hocko <MHocko@...e.com>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        "Huang, Ying" <ying.huang@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux MM <linux-mm@...ck.org>, zwisler@...nel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: [PATCH 0/9] Allow persistent memory to be used like normal RAM

On Tue, Oct 23, 2018 at 11:17 AM Dave Hansen <dave.hansen@...el.com> wrote:
>
> >> This series adds a new "driver" to which pmem devices can be
> >> attached.  Once attached, the memory "owned" by the device is
> >> hot-added to the kernel and managed like any other memory.  On
> >
> > Would this memory be considered volatile (with the driver initializing
> > it to zeros), or persistent (contents are presented unchanged,
> > applications may guarantee persistence by using cache flush
> > instructions, fence instructions, and writing to flush hint addresses
> > per the persistent memory programming model)?
>
> Volatile.
>
> >> I expect udev can automate this by setting up a rule to watch for
> >> device-dax instances by UUID and call a script to do the detach /
> >> reattach dance.
> >
> > Where would that rule be stored? Storing it on another device
> > is problematic. If that rule is lost, it could confuse other
> > drivers trying to grab device DAX devices for use as persistent
> > memory.
>
> Well, we do lots of things like stable device naming from udev scripts.
>  We depend on them not being lost.  At least this "fails safe" so we'll
> default to persistence instead of defaulting to "eat your data".
>

Right, and at least for the persistent memory to volatile conversion
case we will have the UUID to positively identify the DAX device. So
it will indeed "fail safe" and just become a dax_pmem device again if
the configuration is lost. We'll likely need to create/use a "by-path"
scheme for non-pmem use cases.