linux-kernel - Re: [PATCH V3 04/20] nvdimm/label: Update mutex

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: <20250922125125.tm3yapxoxd5lhmat@test-PowerEdge-R740xd>
Date: Mon, 22 Sep 2025 18:21:25 +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
Subject: Re: [PATCH V3 04/20] nvdimm/label: Update mutex_lock() with
 guard(mutex)()

On 17/09/25 03:46PM, Jonathan Cameron wrote:
>On Wed, 17 Sep 2025 18:59:24 +0530
>Neeraj Kumar <s.neeraj@...sung.com> wrote:
>
>> Updated mutex_lock() with guard(mutex)()
>
>Say why.

Sure, I will update it in next patch-set.

>>
>> Signed-off-by: Neeraj Kumar <s.neeraj@...sung.com>
>> ---
>>  drivers/nvdimm/label.c | 36 +++++++++++++++++-------------------
>>  1 file changed, 17 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
>> index 668e1e146229..3235562d0e1c 100644
>> --- a/drivers/nvdimm/label.c
>> +++ b/drivers/nvdimm/label.c
>> @@ -948,7 +948,7 @@ static int __pmem_label_update(struct nd_region *nd_region,
>>  		return rc;
>> +	list_for_each_entry(label_ent, &nd_mapping->labels, list)
>> +		if (!label_ent->label) {
>> +			label_ent->label = nd_label;
>> +			nd_label = NULL;
>> +			break;
>
>Perhaps it will change in later patches, but you could have done
>		if (!label_ent->label) {
>			label_ent->label = nd_label;
>			return;
>		}
>as nothing else happens if we find a match.

Yes, I have updated it in later patch. I will update it here itself.

>
>> +		}
>> @@ -998,9 +998,8 @@ static int init_labels(struct nd_mapping *nd_mapping, int num_labels)
>>  		label_ent = kzalloc(sizeof(*label_ent), GFP_KERNEL);
>>  		if (!label_ent)
>>  			return -ENOMEM;
>> -		mutex_lock(&nd_mapping->lock);
>> +		guard(mutex)(&nd_mapping->lock);
>>  		list_add_tail(&label_ent->list, &nd_mapping->labels);
>> -		mutex_unlock(&nd_mapping->lock);
>
>Not sure I'd bother with cases like this but harmless.
>
>>  	}
>>
>> -	mutex_lock(&nd_mapping->lock);
>> +	guard(mutex)(&nd_mapping->lock);
>>  	list_for_each_entry_safe(label_ent, e, &nd_mapping->labels, list) {
>>  		struct nd_namespace_label *nd_label = label_ent->label;
>>
>> @@ -1061,7 +1060,6 @@ static int del_labels(struct nd_mapping *nd_mapping, uuid_t *uuid)
>>  		nd_mapping_free_labels(nd_mapping);
>>  		dev_dbg(ndd->dev, "no more active labels\n");
>>  	}
>> -	mutex_unlock(&nd_mapping->lock);
>This is a potential functional change as the lock is held for longer than before.
>nd_label_write_index is not trivial so reviewing if that is safe is not trivial.
>
>The benefit is small so far (maybe that changes in later patches) so I would not
>make the change.

Sure, I will revert it back in next patch-set

Regards,
Neeraj

>
>
>
>>
>>  	return nd_label_write_index(ndd, ndd->ns_next,
>>  			nd_inc_seq(__le32_to_cpu(nsindex->seq)), 0);
>