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]
Message-ID: <20250904142023.6zmgow6z5r6sjxcd@test-PowerEdge-R740xd>
Date: Thu, 4 Sep 2025 19:50:23 +0530
From: Neeraj Kumar <s.neeraj@...sung.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc: linux-cxl@...r.kernel.org, nvdimm@...ts.linux.dev,
	linux-kernel@...r.kernel.org, gost.dev@...sung.com,
	a.manzanares@...sung.com, vishak.g@...sung.com, neeraj.kernel@...il.com,
	cpgs@...sung.com
Subject: Re: [PATCH V2 06/20] nvdimm/region_label: Add region label deletion
 routine

On 13/08/25 03:53PM, Jonathan Cameron wrote:
>On Wed, 30 Jul 2025 17:41:55 +0530
>Neeraj Kumar <s.neeraj@...sung.com> wrote:
>
>> Added cxl v2.1 format region label deletion routine. This function is
>> used to delete region label from LSA
>>
>> Signed-off-by: Neeraj Kumar <s.neeraj@...sung.com>
>> ---
>>  drivers/nvdimm/label.c          | 77 ++++++++++++++++++++++++++++++---
>>  drivers/nvdimm/label.h          |  6 +++
>>  drivers/nvdimm/namespace_devs.c | 12 +++++
>>  drivers/nvdimm/nd.h             |  9 ++++
>>  include/linux/libnvdimm.h       |  1 +
>>  5 files changed, 100 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
>> index 94f2d0ba7aca..be18278d6cea 100644
>> --- a/drivers/nvdimm/label.c
>> +++ b/drivers/nvdimm/label.c
>> @@ -1044,7 +1044,8 @@ static int init_labels(struct nd_mapping *nd_mapping, int num_labels)
>>  	return max(num_labels, old_num_labels);
>>  }
>>
>> -static int del_labels(struct nd_mapping *nd_mapping, uuid_t *uuid)
>> +static int del_labels(struct nd_mapping *nd_mapping, uuid_t *uuid,
>> +		enum label_type ltype)
>>  {
>>  	struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
>>  	struct nd_label_ent *label_ent, *e;
>> @@ -1068,8 +1069,23 @@ static int del_labels(struct nd_mapping *nd_mapping, uuid_t *uuid)
>>  		if (!nd_label)
>>  			continue;
>>  		active++;
>> -		if (!nsl_uuid_equal(ndd, &nd_label->ns_label, uuid))
>> -			continue;
>> +
>> +		switch (ltype) {
>> +		case NS_LABEL_TYPE:
>> +			if (!nsl_uuid_equal(ndd, &nd_label->ns_label, uuid))
>> +				continue;
>> +
>> +			break;
>> +		case RG_LABEL_TYPE:
>> +			if (!rgl_uuid_equal(&nd_label->rg_label, uuid))
>> +				continue;
>> +
>> +			break;
>> +		default:
>> +			dev_err(ndd->dev, "Invalid label type\n");
>> +			return 0;
>
>Given you pass in an enum and both elements are covered by other cases
>shouldn't need a default here.

Thanks Jonathan, I will remove the default case in next patch-set

>
>> +		}
>> +
>>  		active--;
>>  		slot = to_slot(ndd, nd_label);
>>  		nd_label_free_slot(ndd, slot);
>
>
>
>> @@ -1268,6 +1285,56 @@ int nd_pmem_region_label_update(struct nd_region *nd_region)
>>  	return 0;
>>  }
>>
>> +int nd_pmem_region_label_delete(struct nd_region *nd_region)
>> +{
>> +	int i, rc;
>> +	struct nd_interleave_set *nd_set = nd_region->nd_set;
>> +	struct nd_label_ent *label_ent;
>> +	int ns_region_cnt = 0;
>> +
>> +	for (i = 0; i < nd_region->ndr_mappings; i++) {
>> +		struct nd_mapping *nd_mapping = &nd_region->mapping[i];
>> +		struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
>> +
>> +		/* Find non cxl format supported ndr_mappings */
>> +		if (!ndd->cxl) {
>> +			dev_info(&nd_region->dev, "Region label unsupported\n");
>
>I'd go with "Unsupported region label".  The other way around kind of implies
>a deficiency in the code, whereas point here is that new stuff may be added to
>the spec that we don't yet understand.

Sure, I will fix it in next patch-set

>
>> +			return -EINVAL;
>> +		}
>> +
>> +		/* Find if any NS label using this region */
>> +		mutex_lock(&nd_mapping->lock);
>
>I'd go for guard here probably as the scope will mean it gets unlocked
>at end of this loop step.
>
>
>		guard(mutex)(&nd_mapping->lock);

Sure Jonathan, I will fix it in next patch-set

Regards,
Neeraj


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ