On Thu, May 28, 2015 at 1:51 PM, Linda Knippers <linda.knippers@xxxxxx> wrote: > On 5/28/2015 3:59 PM, Dan Williams wrote: >> On Thu, May 28, 2015 at 11:36 AM, Toshi Kani <toshi.kani@xxxxxx> 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@xxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
