On Mon, Nov 6, 2017 at 6:50 PM, Elliott, Robert (Persistent Memory)
<elliott(a)hpe.com> wrote:
> -----Original Message-----
> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On
> Behalf Of Dan Williams
> Sent: Monday, November 06, 2017 5:32 PM
> To: Lijun Pan <Lijun.Pan(a)dell.com>
> Cc: linux-nvdimm(a)lists.01.org
> Subject: Re: [PATCH] acpi/nfit: export read_only attribute of dimms
>
> On Mon, Oct 30, 2017 at 1:41 PM, Lijun Pan <Lijun.Pan(a)dell.com>
> wrote:
> > Though flags attribute provides enough information about
> > the dimm, it is nice to export the read_only attribute if
> > bit3 of NVDIMM state flag is set.
> > If error is injected by BIOS, bit3 and bit1 are both set.
> > If DIMM is set to read-only by BIOS, bit3 is set.
> > Hence bit3 is good enough to tell whether the dimm is in
> > read-only mode or not.
>
> Hmm, can you say about more about why we need this additional
> attribute?
>
> Applications don't read and write the DIMM directly, they only
> interface with the DIMM through namespaces of a given region. The
> region device already has a 'read_only' attribute. See
> read_only_show() in drivers/nvdimm/region_devs.c.
A few more points:
1. The full NVDIMM State Flags value is already reported for
the nmem device, so reporting bit 3 separately as "read_only"
would be redundant.
2. For NVDIMM-Ns, the system is not preventing writing to memory;
system firmware is just warning that any writes will not be
persistent across power loss.
3. Considering the different layers:
* the pmem and btt drivers blocks writes themselves, so it makes
sense for them to report ro at the pmem device layer.
* the nmem layer doesn't block writes, so shouldn't report anything
about them being restricted.
* the region layer doesn't block writes, so shouldn't report anything
about them being restricted.
The rationale for surfacing the read_only attribute at the region
level, even though the region does not directly host I/O, is that
regions host attributes that are common to all namespaces in that
region. I see regions as distinct from the nmem level where there is
not necessarily a direct correlation to namespaces, especially when
nmems are optional in the device hierarchy. Regions are also the
gateway interface for setting labels and aggregating state across
several DIMMs.
* the region layer does need to pass along the NVDIMM state flags
to the pmem and btt drivers; read_only might not be the best name
as a user-visible attribute with that information.
The state flags are ACPI specific, so we need to translate to
something Linux generic when it moves to the libnvdimm sub-system.
Read-only when the energy source fails is a preventative measure, the
other state flags indicate that data has already been lost.
Some driver or software might find temporarily writing to those
locations in-place would be useful (e.g. run fsck before copying
the repaired filesystem content to another storage device), so we
shouldn't cut them off unnecessarily.
The read_only attribute can be overridden, i.e. it's only a default
value for safety.