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

[Toshi Kani]

On Tue, 2015-04-28 at 14:24 -0400, Dan Williams wrote:
 :
> +
> +static int nd_acpi_register_region(struct acpi_nfit_desc *acpi_desc,
> +		struct nfit_spa *nfit_spa)
> +{
> +	static struct nd_mapping nd_mappings[ND_MAX_MAPPINGS];
> +	struct acpi_nfit_spa *spa = nfit_spa->spa;
> +	struct nfit_memdev *nfit_memdev;
> +	struct nd_region_desc ndr_desc;
> +	int spa_type, count = 0;
> +	struct resource res;
> +	u16 spa_index;
> +
> +	spa_type = nfit_spa_type(spa);
> +	spa_index = spa->spa_index;
> +	if (spa_index == 0) {
> +		dev_dbg(acpi_desc->dev, "%s: detected invalid spa index\n",
> +				__func__);
> +		return 0;
> +	}
> +
> +	memset(&res, 0, sizeof(res));
> +	memset(&nd_mappings, 0, sizeof(nd_mappings));
> +	memset(&ndr_desc, 0, sizeof(ndr_desc));
> +	res.start = spa->spa_base;
> +	res.end = res.start + spa->spa_length - 1;
> +	ndr_desc.res = &res;
> +	ndr_desc.provider_data = nfit_spa;
> +	ndr_desc.attr_groups = nd_acpi_region_attribute_groups;
> +	list_for_each_entry(nfit_memdev, &acpi_desc->memdevs, list) {
> +		struct acpi_nfit_memdev *memdev = nfit_memdev->memdev;
> +		struct nd_mapping *nd_mapping;
> +		struct nd_dimm *nd_dimm;
> +
> +		if (memdev->spa_index != spa_index)
> +			continue;

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.

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.

Thanks,
-Toshi








--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/