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]
Date:	Thu, 28 May 2015 12:59:56 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Toshi Kani <toshi.kani@...com>
Cc:	"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 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...
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ