linux-kernel - Re: [PATCH] cxl/region: Fix cxlr

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: <66314d8343103_10c2129413@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date: Tue, 30 Apr 2024 12:58:59 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>, Li Zhijian
	<lizhijian@...itsu.com>
CC: <dave@...olabs.net>, <dave.jiang@...el.com>, <alison.schofield@...el.com>,
	<vishal.l.verma@...el.com>, <ira.weiny@...el.com>,
	<dan.j.williams@...el.com>, <linux-cxl@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cxl/region: Fix cxlr_pmem leaks

Jonathan Cameron wrote:
> On Sun, 28 Apr 2024 11:07:48 +0800
> Li Zhijian <lizhijian@...itsu.com> wrote:
> 
> > Before this error path, cxlr_pmem pointed to a kzalloc() memory, free
> > it to avoid this memory leaking.
> > 
> > Fixes: f17b558d6663 ("cxl/pmem: Refactor nvdimm device registration, delete the workqueue")
> > Signed-off-by: Li Zhijian <lizhijian@...itsu.com>
> 
> Fix is good, but this looks like nice case for conversion to cleanup.h stuff
> perhaps better to just do that?  Would need a small amount of dancing
> on the final return to return cxlr->cxlr_pmem + pointer steal
> when setting cxlr->cxlr_pmem a few lines up.
> 
> Also guard for the rwsem.
> 
> Dave, Dan, worth doing or take this minimal fix and spin around later?
> 
> If you think this is the way to go.
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>

I had spun up the conversion patch as a replacement in response to this.
However, after looking at that I think merging this fix with a follow-on
cleanup is they way to go because the cleanup touches locking, memory
allocation, and changes the calling convention.

Reviewed-by: Dan Williams <dan.j.williams@...el.com>

I'll send the follow-on cleanup shortly.