linux-kernel - Re: [Linux-nvdimm] [PATCH v2 08/20] libnd, nd_acpi: regions (block-data-window, persistent memory, volatile memory)

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] [day] [month] [year] [list]

Message-ID: <CAPcyv4j3niw+Txyw_wwws7ynt5bc4gG46PhpC4cp5nMo8QR1Ww@mail.gmail.com>
Date:	Thu, 28 May 2015 13:58:38 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Linda Knippers <linda.knippers@...com>
Cc:	Toshi Kani <toshi.kani@...com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Neil Brown <neilb@...e.de>,
	Greg KH <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Robert Moore <robert.moore@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	Christoph Hellwig <hch@....de>
Subject: Re: [Linux-nvdimm] [PATCH v2 08/20] libnd, nd_acpi: regions
 (block-data-window, persistent memory, volatile memory)

On Thu, May 28, 2015 at 1:51 PM, Linda Knippers <linda.knippers@...com> wrote:
> On 5/28/2015 3:59 PM, Dan Williams wrote:
>> On Thu, May 28, 2015 at 11:36 AM, Toshi Kani <toshi.kani@...com> wrote:
>>> On Sat, 2015-05-09 at 16:55 -0700, Dan Williams wrote:
>>>> On Mon, May 4, 2015 at 1:26 PM, Toshi Kani <toshi.kani@...com> wrote:
>>>>> On Tue, 2015-04-28 at 14:24 -0400, Dan Williams wrote:
>>>  :
>>>>>
>>>>> The libnd does not support memdev->flags, which contains "Memory Device
>>>>> State Flags" defined in Table 5-129 of ACPI 6.0.  In case of major
>>>>> errors, we should only allow a failed NVDIMM be accessed with read-only
>>>>> for possible data recovery (or not allow any access when the data is
>>>>> completely lost), and should not let users operate normally over the
>>>>> corrupted data until the error is dealt properly.
>>>>
>>>> I agree with setting read-only access when these flags show that the
>>>> battery is not ready to persist new writes, but I don't think we
>>>> should block access in the case where the restore from flash failed.
>>>> If the data is potentially corrupted we should log that fact, but
>>>> otherwise enable access.  I.e. potentially corrupt data is better than
>>>> unavailable data.  It's up to filesystem or application to maintain
>>>> its own checksums to catch data corruption.
>>>>
>>>>> Can you set memdev->flags to nd_region(_desc) so that the pmem driver
>>>>> can check the status in nd_pmem_probe()?  nd_pmem_probe() can then set
>>>>> the disk read-only or fail probing, and log errors accordingly.
>>>>
>>>> Will do.
>>>
>>> I do not see this change in v4.  Is this part of the pending changes
>>> behind this release?
>>
>> Yes, I was holding it off until we had an upstream acceptance baseline
>> set.  That is on hold pending Christoph's review.  He's looking to
>> come back next Wednesday with deeper review comments.  The runway to
>> land this in v4.2 is running short...
>
> Hi Dan,
>
> Do you have a short list of pending changes, especially if some weren't
> discussed on the list?  That might help reviewers.
>
> I know we're still looking at and trying a number of things, like using
> the BTT on today's NVDIMMs and adding another example DSM, so we will
> have more feedback and patches and may need to adapt some of the
> structure to do that.  This can happen after the initial patches are
> pulled in but I just wanted to let you know where we are.  Not sure
> about others.
>

It seems it's just Christoph that has asserted there are things he'd
liked changed, so I don't see much potential for confusion in letting
out the pending backlog.  I'll see to it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/