From: Dan Williams <dan.j.williams@intel.com>
To: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Jane Chu <jane.chu@oracle.com>
Subject: Re: [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax_range()
Date: Thu, 17 Dec 2020 19:10:04 -0800 [thread overview]
Message-ID: <CAPcyv4jxgbawSbYF39g857fiDCRmMACr1u-OiSWkz4M0+2UPbQ@mail.gmail.com> (raw)
In-Reply-To: <20201120092251.2197-1-thunder.leizhen@huawei.com>
On Fri, Nov 20, 2020 at 1:23 AM Zhen Lei <thunder.leizhen@huawei.com> wrote:
>
> Swap the calling sequence of krealloc() and __request_region(), call the
> latter first. In this way, the value of dev_dax->nr_range does not need to
> be considered when __request_region() failed.
This looks ok, but I think I want to see another cleanup go in first
before this to add a helper for trimming the last range off the set of
ranges:
static void dev_dax_trim_range(struct dev_dax *dev_dax)
{
int i = dev_dax->nr_range - 1;
struct range *range = &dev_dax->ranges[i].range;
struct dax_region *dax_region = dev_dax->region;
dev_dbg(dev, "delete range[%d]: %#llx:%#llx\n", i,
(unsigned long long)range->start,
(unsigned long long)range->end);
__release_region(&dax_region->res, range->start, range_len(range));
if (--dev_dax->nr_range == 0) {
kfree(dev_dax->ranges);
dev_dax->ranges = NULL;
}
}
Care to do a lead in patch with that cleanup, then do this one?
I think that might also cleanup a memory leak report from Jane in
addition to not needing the "goto" as well.
http://lore.kernel.org/r/c8a8a260-34c6-dbfc-1f19-25c23d01cb45@oracle.com
next prev parent reply other threads:[~2020-12-18 3:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 9:22 [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax_range() Zhen Lei
2020-12-18 3:10 ` Dan Williams [this message]
2020-12-18 6:02 ` Leizhen (ThunderTown)
2020-12-18 6:09 ` Leizhen (ThunderTown)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPcyv4jxgbawSbYF39g857fiDCRmMACr1u-OiSWkz4M0+2UPbQ@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=jane.chu@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=thunder.leizhen@huawei.com \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).