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: <68cee7e7a00f5_1c391729430@iweiny-mobl.notmuch>
Date: Sat, 20 Sep 2025 12:44:07 -0500
From: Ira Weiny <ira.weiny@...el.com>
To: Dave Jiang <dave.jiang@...el.com>, Neeraj Kumar <s.neeraj@...sung.com>,
	<linux-cxl@...r.kernel.org>, <nvdimm@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <gost.dev@...sung.com>
CC: <a.manzanares@...sung.com>, <vishak.g@...sung.com>,
	<neeraj.kernel@...il.com>, <cpgs@...sung.com>
Subject: Re: [PATCH V3 04/20] nvdimm/label: Update mutex_lock() with
 guard(mutex)()

Dave Jiang wrote:

[snip]

> > @@ -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);
> 
> I would not mix and match old and new locking flow in a function. If you are going to convert, then do the whole function. I think earlier in this function you may need a scoped_guard() call.
> 

FWIW I would limit the changes to __pmem_label_update() because that is
the function which benefits from these changes.

> >  	}
> >  
> >  	if (ndd->ns_current == -1 || ndd->ns_next == -1)
> > @@ -1039,7 +1038,7 @@ static int del_labels(struct nd_mapping *nd_mapping, uuid_t *uuid)
> >  	if (!preamble_next(ndd, &nsindex, &free, &nslot))
> >  		return 0;
> >  
> > -	mutex_lock(&nd_mapping->lock);
> > +	guard(mutex)(&nd_mapping->lock);
> 
> So this change now includes nd_label_write_index() in the lock context as well compare to the old code. So either you should use a scoped_guard() or create a helper function and move the block of code being locked to the helper function with guard() to avoid changing the original code flow.
> 

Sure you could do this but again I don't think these updates are worth
this amount of work right now.

Ira

> DJ
> 
> >  	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);
> >  
> >  	return nd_label_write_index(ndd, ndd->ns_next,
> >  			nd_inc_seq(__le32_to_cpu(nsindex->seq)), 0);
> 
>